It was just over 10 years ago, at the annual Catalyst conference, that provisioning rivals Business Layers and Access360 sat on different sides of the conference meeting room (the ballroom of the Mariott hotel in San Diego) and hurled catcalls and invective at each other. A year later, they’d matured (as had the technology) and – under the auspices of the Organization for the Advancement of Structured Information Standards (OASIS) joined to help form the Provisioning Services Technical Committee. A year after that, in 2003, the committee demonstrated the first release of the Provisioning Services Markup Language, soon changed to the Service Provisioning Markup Language (SPML), in action. We saw that XML messages containing provisioning data could be exchanged between and among different provisioning engines. Joy ensued.
Followed by ennui. Nobody did very much with SPML, but it was, after all, just a 1.0 release – and no one can do much with a 1.0 release.
Just as I was beginning to think that SPML might be merely an asterisk in the history of Identity Management, the wonderful folk at OASIS, on behalf of the Provisioning Services Technical Committee (they never did change THEIR name!) released version 2 of SPML into the wild in 2006.
Followed by even greater ennui.The thought began to emerge that the provisioning vendors, not wishing to give their competitors any advantage, were deliberately dragging their feet on implementing provisioning standards.
Fast-forward five years to the spring of 2011.A mixed group of cloud service providers (Google, Salesforce.com et al), identity product vendors (Ping Identity, UnboundID, Okta and others) and other interested parties (VMware and Alcatel/Lucent) met and decided: 1)that there was a need for electronic provisioning of cloud services; and 2) that SPML wasn’t the answer.
Provisioning vendors did pay lip service to SPML in their products, and "best practice" lists for customers encouraged them to include SPML capability as a checkbox on their RFPs, but few, if any, application vendors had implemented SPML in their production services. It was also thought to be slow and ponderous in practice. Ping’s CTO, Patrick Harding, said about SPML: “My quick analysis would be to say that SPML looks, feels and acts like a boat anchor.” Harding also noted that customers simply want something that works and that the adoption of REST (Representational state transfer) and JSON (JavaScript Object Notation) in the Cloud is exploding (as opposed to SPML’s XML-basis).
What this group has created is SCIM (Simple Cloud Identity Management).Initially, I was opposed to SCIM – I thought that SPML could be moved forward to encompass cloud-based services relatively easily. The folks at Oracle evidently thought so too, as they introduced a new draft to the Provisioning Services Technical Committee (the SPML folks) at OASIS touting what they called RESTpml. The response to the call for a RESTful binding of SPML was pretty much what it was for the original SPML – none.
My colleague, Martin Kuppinger, also voiced some skepticism about SCIM ("SCIM – will SPML shortcomings be reinvented?") last spring when he said "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."I also had noted that no provisioning vendor had stepped forward to embrace SCIM. That’s now changed, as Courion announced their support earlier this month.
So it’s time I ate my words and changed my opinion. I’ll leave Martin to decide if recent events have been enough for him to change his.SCIM is getting support from vendors. it’s also recently adapted to include schema extensions deemed necessary for it to be used for provisioning within the datacenter. It appears to be a standard whose time has come.
So what is SCIM? Here’s what the group creating the specification say:“The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud.”
For those of you interested in how it might work, there’s a very good use case detailed here.SCIM now appears to be our best chance for any sort of public provisioning standard, something we desperately need (and have needed for years). It may be time to overlook its shortcomings, plan for the second version and put it into practice both for the cloud and for the datacenter.