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.
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.