Gartner’s Identity and Privacy Service (IdPS) has closely tracked provisioning standards since 2003. I published our first research document on Service Provisioning Markup Language (SPML v2) in early 2006. Additionally, I published a realistic assessment of developing an SPML service in early 2010. A few months later, I worked with industry leaders to publish a statement on SPML’s viability and the need for realistic provisioning standard.
I closely track the Simple Cloud Identity Management (SCIM) standard. Gartner was the first research and advisory firm (as far as I know) to publically support SCIM (May of 2011). At that time, some members of the analyst community were unenthusiastic and publically recommended staying with SPML. Things have since moved in a more positive direction. In an effort to learn more about the standard, I developed a SCIM consumer prototype, using REST, JSON, and Unbound ID’s Directory Server running in an EC2 instance. I’ve developed heterogeneous “user account management” solutions since 1996. In short, I am a passionate about the topic of provisioning.
After seeing members of the SCIM committee propose features and capabilities in addition to the core CRUD operations, I became concerned about “kitchen sinking”, something that exists in SPML v2 and something I warned about in my blog last year. Kitchen sinking will over-complicate the SCIM standard and delay its release. I contacted Trey Drake, Architect at Unbound ID with my concerns. Trey is one of the leaders working on SCIM, as well as the editor of the SCIM protocol document. He provided insightful responses; I hope you find them as helpful as I did. Based upon his statements, it appears that SCIM remains on track.
There’s also good news today from the IETF. It approved the creation of the SCIM birds-of-a-feather (BoF). The BoF is a significant first step as BoF acceptance acknowledges the basis for a SCIM standard within IETF.
It seems that much thought has gone into the 1.0 specification. People are coding to it. I know a vendor that supports it (UnboundID). Why doesn’t the committee explicitly state that any IETF work will be compatible with 1.0? Without that, people will wait, which will hold up adoption of something that is needed in the industry. As a background question, does IETF standardization really buy anything for the industry if people already like the 1.0 specification and the vendors are integrating it (or have roadmaps to do so)? Is the IETF process a distraction?
We stated the goal for backward compatibility in the strongest way we could. Things can obviously change, but we’ve built the very strong desire to remain backwards compatible into the proposed charter. In practice, I don’t see additional risks for “spec drift” in IETF as compared to keeping SCIM in a working group.
After all, the major SCIM players will participate in the IETF committee. It is clear that folks like SCIM— there are many implementations, webcasts, and blogs popping up all over the place. We’re obviously addressing a pain point. The mailing list membership now exceeds 250 individuals; I’m still surprised at the number of people investing time and effort into the specification. The growing membership and rapid uptake means that strong governance will be essential.
For the 1.0 specification, the core authors/contributors just did “the right thing” as we were all of similar minds. The specification was completed very quickly. With the expansion in the number of stakeholders, I’m expecting more contention, hence stronger governance will be required.
In short, IETF will help with governance. History proves it will take a long time to get the specification through IETF; the recent experience with OAuth 2 comes to mind. But that didn’t stop SalesForce, Google, Facebook, and others from touting and implementing OAuth 2. The goal of the IETF effort is to strengthen governance and broaden participation while staying the course with SCIM 1.0. It will take a long time to morph SCIM into an IETF standard and in the meantime those implementing 1.0 will benefit.
Do you feel like the folks on the committee are pushing to explicitly include authorization frameworks into the standard? It feels like a distraction and an opportunity to delay adoption and make it more complicated.
There are some that want to, but most do not. I will continue to evangelize “opaqueness”. That said, I’m in favor of vendors or other working groups extending the SCIM model to fit their needs.
Do people want to augment the core standard to better manage objects besides users and groups?
Yes. Note that any object schema can be represented in SCIM. That said, I’m not in favor of representing the kitchen sink —though I do believe there is utility in representing other common objects in the specification. Devices may be a candidate (think smartphones and tablets). For example, if I implement an IDP, I may want to provision devices and associate them with a user just as I do groups today.
As an aside, our implementation enables the representation of any LDAP object class as a SCIM object. In effect, it is s a generic REST API for the Unbound ID Directory and Synchronization Server. I wrote some stuff about the topic years ago (though I implemented it differently). Finally, my goal has been achieved!
I can see the utility of managing devices, but shouldn’t this be tackled via custom schema later and let folks move to more pressing standards work?
Yes, I expect most of this stuff to be done via extension a la LDAP.
Why is there a strong desire to bind SCIM schema to the Lightweight Directory Access Protocol schema? SCIM starts to look like DSML and SPML (which is to say old school). It seems that LDAP-fluent people can do this for themselves. The hierarchical object class syntax of LDAP doesn’t belong in such a clean, simple standard.
But we won’t change SCIM. The idea is to provide guidance to implementers on how to map SCIM in other representations. For example, I, along with other working group members, are drafting a binding that describes how one may represent SCIM in LDAP. Others will join in and that will become a best practice. That’s the idea anyway.
OASIS or Mirage: Standards-Based Provisioning (subscription required)
Atom and LDAP sitting in a tree… (Trey Drake)