SCIMming the Surface of User Provisioning

This should be interesting!

By all accounts, one of the main reasons that SPML never achieved traction was that application vendors were not involved in developing or deploying the standard. The effort to standardize provisioning of accounts was driven largely by the provisioning engine vendors. The result was an unwieldy standard that nobody could figure out how to support, and which seemed to have one fatal flaw – the lack of a standardized schema for user accounts. Last year, it seemed like SPML was being put on life support.

Now, a new effort aimed at solving this most intractable of identity problems would seem to be trying a new route. It’s called Simple Cloud Identity Management, or SCIM (born at last falls IIW as Cloud LDAP). Here are some highlights from what I see:

• It has the backing of such heavyweight (cloud) application vendors as Google and Salesforce (in addition to having the folks at Ping Identity working on it)
• It is narrowly focused on CRUD (Create, Read, Update, Delete) of user accounts, supporting both user attributes and user roles (I guess calling it Simple Cloud User Management, which is what it really is, would have been a non-starter!)
• It is REST-based (obviously)
• It provides a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols

Last year, I spent a fair amount of time exploring the world of federated provisioning, and talked about the different models that needed to exist – advance/batch provisioning, JIT provisioning through SSO channel, JIT provisioning with pull from identity provider. At the time, I held the opinion that there wouldn’t be just one standard that would play in this area. SPML would still be used for batch provisioning, but the pull-based models in JIT provisioning would combine SAML/OpenID with something like the Identity Governance Framework (which itself describes a user schema based on iNetOrgPerson). Since then, what I have come to realize is that the negative baggage associated with SPML is so heavy that folks like Google and Salesforce were never going to be become proponents of it. Also, there are specific performance and behavior characteristics needed to succeed in cloud environments that would rule out a heavy standard like SPML from the start. And any standard in this space would have to be RESTful. So last month, when a CSO asked me at a conference roundtable if SPML would ever gain traction for provisioning to cloud services, I told him that my considered opinion was No. There is just too much baggage there.

Is SCIM really the answer? Only time will tell. The real challenge will be in making sure that SCIM as a standard can support all user provisioning use cases, not just a very narrow band that needs to be supplemented with proprietary schemes or other efforts. SCIM won’t succeed if administrators still have to log into the SaaS applications web interface to “finish” creating the account. Would SCIM support creating 100s of accounts in one batch command (and appropriate error messages/feedback) for that day when all the interns start at a company and need accounts provisioned? How would compliance requirements be met when there is nothing in the standard that allows to query for changes made to the account? Some of the provisioning connectors need to communicate with the target application ahead of time to determine if the changes being sent would result in SoD violations. Would SCIM provide an API for this?

And do we really want to have one standard for internal applications and a different one for cloud-based applications? The answer most definitely is NO.

I’m a little ambivalent about SCIM at this point. In my opinion, SPML just was not going to make any inroads, so a fresh approach was definitely called for. But there were efforts like IGF that could have been leveraged here instead of starting from scratch. And it will be interesting to see if a robust provisioning standard can develop from an agile effort lacking the rigor of an OASIS standards process. I’m looking forward to exploring these topics at IIW in MountainView next week (where I will be for the first day and a half). Should make for some vigorous debate.