23.04.2011 by Martin Kuppinger
There is a new initiative driven by Google, salesforce.com, and Ping Identity called SCIM (Simple Cloud Identity Management). It claims to overcome the shortcomings of SPML (Simple Provisioning Markup Language), a standard being around for some 10 years. SPML has the target of being a standard for provisioning information between systems. It is supported by most provisioning and access governance tools, but only few target systems. SAP probably is the most important supporter.
Google, salesforce.com, and others in the cloud don’t support SPML. Thus, provisioning to these systems requires using proprietary APIs, if available at all – Google and salesforce.com provide such APIs, but not every cloud provider does. To overcome this, work on SCIM has started.
The first question however is: Why not use SPML? The main reason might be that SPML is XML-based, not focusing on REST which appears to be the somewhat more efficient (and especially, more accepted) way to implement standards for the cloud. Another might be that SPML is moving forward very slowly, if moving at all. There are many defencencies in SPML, no doubt about that. These start with the limited support by non-IAM-vendors. There are technical limitations as well, including performance issues in large scale deployments and limitations regarding what could be provisioned via SPML.
Nevertheless, I’d like to ask two questions:
- Wouldn’t it be better to join forces of SPML and SCIM to build a SPML version 3.0 which supports REST as well?
- If working on a new or improved standard, wouldn’t it make sense to address all relevant use cases? SPML doesn’t today and SCIM is not likely to do, when looking at the information provided today.
The first aspect seems to be more sort of a political issue between different vendors. However, having two standards doesn’t help anyone at the end of the day.
That’s even more true if both standards are too lightweight and don’t cover all the companies need today. When looking at the little piece of SCIM specification published it looks like SCIM will only touch the surface of what is required. The use cases are focused on providing user information to cloud services. However, the topic isn’t identity management, it is identity and access management. The access or entitlement part is the big thing to solve. Dealing with different APIs of different cloud providers for identities is an issue, but it isn’t the biggest one – several vendors (federation, classical on-premise provisioning, cloud provisioning) have addressed this at least for the leading cloud providers.
But what about controlling who is allowed to do what in these services? How to manage entitlements, e.g. group membership, authorization rules, and other things? XACML is a standard which supports this, but again there is little to no support by cloud providers for XACML – like with SPML. Thus, when starting to define a new standard, it shouldn’t be a too simple one, which SCIM appears to be at that point of time. It has one which covers all relevant use cases of identity and access management. There is only limited value in providing user information to a cloud service but still having to enter the proprietary web administration interface (or using some proprietary APIs) to control access for that user, to define groups, roles, policies, and so on.
My conclusion: There should be open standards for identity and access management in the cloud. Building on proprietary services is about repeating errors made before. But a new standard shouldn’t be too limited from the beginning. That, by the way, is one of the reasons I see behind the very limited success of SPML: It was too limited. I remember a conversation with one of the leading people involved in SPML years back from now where I suggested looking at use cases like supporting client lifecycle management solutions, e.g. tools supporting (amongst other features) software deployments. There are vendors today in the client lifecycle management market building custom integrations to HR or provisioning tools today, but not based on SPML – because they have never heard about SPML and because SPML never looked at this use case.
There might be a good reason for an effort like SCIM. But just being a REST-based standard but not really thinking beyond what SPML supported won’t solve the real world problems. Thus I strongly recommend to rethink SCIM and to look at significantly extended use cases.
If someone likes to discuss this with me in person, best is to meet at at EIC in Munich, May 10th to 13th.
21.04.2011 by Martin Kuppinger
In these days of slowly increasing maturity of Cloud Computing it becomes more and more obvious that and why IT depends on a well thought layer which I tend to simply call “infrastructure”. I have two simple pictures of IT in mind:
- The somewhat classical model of platform, infrastructure, and software, like found in PaaS, IaaS, and SaaS in the common Cloud Computing meta models. It’s about hardware and other foundational components like operating systems, about the layer between to manage and orchestrate everything, and the applications themselves.
- Another view consists as well of three layers. The services exposed to the users (i.e. in most cases the business) on top, the service production (either in the public cloud or a private cloud or in non-cloudified IT environments) at the bottom – and a layer in between which again is used for managing and orchestrating everything. Again, this layer might best be called “infrastructure”.
This layer is which connects everything. Thus, efficiency and effectivity of this layers are the foundation of efficiency and effectivity of the entire IT. Optimizing this layer allows to better connect the available services to the business demands. It allows to manage the different layers in the cloud.
When looking at that layer, there are some few key elements:
- Service Management, e.g. the entire area of procurement, service request management, accounting, availability, performance, and whatever it requires to ensure that the services are delivered as expected
- Information Security Management, including IAM (Identity and Access Management) and at least IT GRC (Governance, Risk Management, Compliance)
- Application Infrastructures, e.g. middleware allowing to connect services, to enhance them if required and to do the orchestration
Did I miss important elements? OK, there is the classical IT security, however that’s part of Information Security – the reason we are looking at IT security is to protect information. You might add some other elements, however I tend to keep this model simple.
To me it appears to be more important to look at the dependencies of the three services. Information Security and Service Management have to work hand in hand, to ensure that access to services is restricted and controlled. Applications and Information Security are tightly related – think about how to build secure apps. And applications are, at the end of the day, nothing else than services which have to be managed.
I personally believe that starting with such a model and outlining the blueprint for your future IT definitely helps in separating the important from the less important things and to focus on building an IT ecosystem in your organization which is stable and works with whatever you plan to do in the Cloud.
See you at EIC 2011 in Munich, May 10th to 13th.
14.04.2011 by Martin Kuppinger
User Management in SAP environments has fundamentally changed over the course of the last 10 to 15 years. When centralizing user management became an increasing demand of SAP customers, SAP introduced CUA (Central User Administration) several years ago. However, CUA has some restrictions and many customers have chosen other options like provisioning tools from 3rd party vendors. Thus, SAP has decided to change the approach. SAP NetWeaver Identity Management no is the strategic recommendation of SAP for managing users across SAP systems. If blogged about that before here and here.
We have recently run a survey on what SAP customers are doing today and plan to do. The range of SAP systems in production is pretty big, from several respondents using 4 to 10 instances, but a few having a farge bigger number in use, up to 200. Amongst the responding organizations, close to a quarter is using CUA today for all production instances, while another third is using CUA for some of the production instances. That might be based on the fact that CUA doesn’t support all SAP systems. The reason might be also that CUA hasn’t deployed as the strategic tool for user management in the SAP environment, covering all instances.
Most of the organizations started using CUA early, but some few deployed the tool after 2007 and thus after the first strategic announcements of SAP that SAP NetWeaver Identity Management will be the successor for CUA. However, most customers will migrate from CUA. Roundabout 60% plan to migrate to SAP NetWeaver Identity Management, but only one out of ten companies plans to move to provisioning tool of another vendor. Interestingly, some 30% of the organizations don’t plan to replace CUA within the foreseeable time. From the ones migrating roughly half have started their migration, while most of the others will make that move within the next two years.
The numbers prove that SAP appears to be successful with their strategy of migrating from CUA to SAP NetWeaver Identity Management. The customers tend to choose SAP NetWeaver Identity Management for user management within their SAP environments. Given that there are sufficient architectural options for IAM today, with Access Governance solutions or Service Request portals on top of one or multiple provisioning tools below that, this approach still leaves sufficient strategic options for the holistic view on IAM and Access Governance for the entire, heterogeneous IT environment.
To learn more about these options and how to best manage SAP and other environments from the user management, access management, and IT governance perspective, visit EIC 2011 in Munich, May 10th to 13th.
06.04.2011 by Martin Kuppinger
Today I stumbled about an interesting survey. The core result: More than three-quarters of financial institutions learn of fraud incidents when notified by their own customers. The quote I like most is: “In other words, despite the availability today of world-class fraud detection technology, despite broad awareness of the current fraud threats and incidents – nothing spreads faster than word of a breach”. Fascinating, isn’t it!? However, it is really somewhat irritating.
There is some reason for financial institutions not to invest as much as they could and should in security. Security comes at a cost and financial institutions still balance these costs against the fraud-related losses. I doubt that this equation really works out as expected, but I had this discussion more than once – frequently with CIOs and CISOs which don’t have the budgets they’d like to have around security.
However, taking some risk is a valid approach. Given that there never ever will be the perfect security, a 100% security, everyone has to balance the cost of security and the (potential) cost of incidents happening. That’s the same approach everyone uses in daily life when deciding about insurances. The fundamental problem in that area is that risks tend to be rated too low whilst costs are seen much more realistic. That’s especially true when it comes to severe issues which might affect the net cash inflow, because that heavily affects the business. However, such risks are frequently ignored or missed when looking at IT security in financial institutions, leading to an underestimated risk and thus a lack of willingness to invest in security.
Another problem is the frequent lack of a holistic security strategy. Attacks at the operating system layer are still possible even when security at the application layer is good – and so on… Investing in point solutions might give the feeling of security, but it seldomly leads to real security.
However, all this doesn’t explain why financial institutions not even are aware of incidents in some many situations. Even when someone takes a risk, he should have controls in place which provide the fraud information. Not doing this is just inacceptable because it moves the things from risk to uncertainty – and thus is against the governance requirements the management has to fulfill. Not knowing about fraud is a clear indicator for an insufficient risk management, because risks are just ignored.
From my perspective, financial institutions have to act in that area by looking at all risks and by acting appropriate – by at least knowing, but better mitigating these risks.
EIC 2011 will have several sessions around security for financial institutions and there will be a lot of experts from the finance industry attending – thus it’s a perfect place to meet with peers and to discuss.