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.

Tags: Cloud Security, Federated Provisioning, SCIM, SPML

This was the topic of discussion at a SIG on Standards-based Provisioning organized by Gartner’s Mark Diodati at the recent Catalyst conference. The meeting was attended by some really smart folks in the community, and engendered a lively discussion on the future of SPML and the direction it should take. Mark has published a statement on the Gartner blog network that reflects the outcome of the discussion. Given the recent reboot of the Provisioning Services Technical Committee at OASIS, this is an important document for everyone concerned to read.

One of the most important points raised during the meeting was this:

In trying to address every possible use case, interoperable provisioning services leveraging the SPML v2 standard became impractical. Since the approval, few (if any) conformant implementations exist due to the complexity of the v2 standard.

The path to success in the standards world is based on a focused approach to solving specific use cases. No standard can be all things to all people, and with provisioning in particular, we need to recognize that there are different approaches that solve the challenge in optimal ways for their use cases (my recent assertion regarding IGF as underlying pull-based provisioning is an example). So there need to be an effort to continue refinement of SPML 2.0, making it simpler to implement and based on specific use-cases that are of interest to the community. If you have such use-cases, please consider joining the discussion within the PSTC and submitting them there. There is much that needs to be done.

And a big thank you to Mark for pulling together the SIG. It was an excellent and timely effort, one that I hope proves instrumental in accomplishing it’s goal.

Tags: Burton Catalyst Conference, Cat10, Provisioning, SPML

On Wednesday, I gave a talk entitled “Beyond SPML: Access Provisioning in a Services World” which built on my Gluecon talk and work with Fusion architecture to provide a vision for the future of provisioning. The central thesis is that as we move from Push to Pull models in Identity, provisioning becomes a key component in making sure that policy and process controls are still enforced. But this requires a fundamental evolution in application and middleware architecture towards services-oriented security and externalized identity.

I was extremely gratified to receive lots of positive validation and feedback about the vision I expressed in my presentation. And it really fit in with the theme flowing through the presentations in the provisioning section, which was focused on moving to a more streamlined, manageable, scalable provisioning future. It also echoed sentiment that provisioning is a multi-faceted problem with different interaction points and flows and will therefore require a combination of standards rather than just one standard. This was really driven home by the extremely interactive SPML SIG meeting that I participated in (organized by Mark Diodati) where there was generally agreement that SPML needs to get really focused on specific use cases rather than trying to be all things to all possibilities.

I am looking  for input, so check out the deck and leave me comments on this post. I will definitely be building on the ideas in there with our identity management team to move the vision of service-oriented security forward. But for it to be useful, it has to resonate with the IdM and application development communities. And that’s where we all have to work together in making this a reality.

Tags: Burton Catalyst Conference, Cat10, Federated Provisioning, Provisioning, SPML

But as Mark also points out, “…it (or something like it) is desperately needed“. Because access provisioning is still the most complicated engagement in any identity management project, and the biggest complexity currently comes from the need to develop, customize, deploy and maintain connectors to hundreds, even thousands of systems. The cloud amplifies the issues to emerge, since without standardization, an enterprise simply will not be able scale out to meet the management needs of their environment.

At Oracle, we have been talking about Service-Oriented Security for a while. The idea is simple – all the security functions, which includes identity management, need to take the form of discrete, easy to consume, standardized services that are part of the platform on which applications are built. This has always been an easy concept to understand when discussing certain service categories like authentication. But provisioning has been a tougher nut to crack.

Provisioning systems today add a vital business process layer to your identity management deployment, dealing as they do with the lifecycle management of identities and the orchestration of policies, rules and workflows around that. So even in a future where architectures will rely on the “pull” model (as Bob Blakley has been talking about), there will be a need for the more complex applications to interface with a provisioning service (different from the attribute service use case) to deal with lifecycle management issues around application access. This is where we believe the next iteration of SPML (however radically different it looks) needs to fit in. This idea is illustrated in the figure below.

This is one of the challenges we have been trying to solve as part of our Fusion architecture project. Do we have it solved? Well, we’ve started the journey at least. Asking applications to come around to a new architecture and way of thinking takes time. And we have to remember that there are still a lot of applications that will not be dropping their user tables and identity silos any time soon, so we have to be mindful of accommodating those applications as well.

Is SPML on life support? Not quite, judging from all the RFP requests that still ask for it to be supported. But it desperately needs some energy to be put behind it. And it needs to adapt to these new architectures, new use cases and the ecology of standards that is far out-pacing it. I believe Oracle (led by folks like Prateek Mishra) will be looking to take some leadership in the evolution of the standard. Let’s see if we can turn things around.

Tags: Identity Services, IdM Standards, Provisioning, Service-Oriented Security, SPML

One of the topics that has been fodder for some animated discussion has been the topic of federated provisioning. As the cloud has brought federated authentication back into focus, it has also shone a light on the need for federated provisioning to power cloud identity. After a very interesting discussion that I had with some folks who are looking at identity in the cloud, I posed the following question on Twitter:

Had an interesting discussion this morning on how OAuth could be to federated provisioning what OpenID is to federated SSO. Any takers?

The Thesis

Federated provisioning is about creating an account with appropriate privileges in underlying systems on the Relying Party side when triggered by an authentication event (user comes to the RP service from the Identity Provider, or IdP, side). Further, the authentication token being presented to the RP does not contain sufficient claims (attributes, etc) for the systems on the RP side to create the necessary account (there are other scenarios, of course, but this is the common one I am trying to address). Consequently, we have a need for the RP to get provisioned with data from the IdP side.

Now in my post “The Thing About Federated Provisioning“, I pointed out that there are challenges in doing all of this just-in-time. Enterprises often resort to out-of-band pre-provisioning of accounts across the domain boundaries, which is where SPML proves to be adequate. But the demand for JIT mechanisms still exists. The cloud exacerbates this problem greatly, because pre-provisioning is pretty much impossible when you move up to the scale and loose coupling of the cloud. And the nature of SPML requires that extensive integration be done before the connection between the RP and the IdP can go live.

And this is where I believe OAuth could play a role. OpenID is already viewed as a lightweight solution for enabling federated authentication, with attribute exchange supporting the simpler data transport scenarios. We could now augment this flow by adding an OAuth-based data provisioning mechanism that allows a Provisioning Service on the RP side to connect back to a Provisioning Service on the IdP side and retrieve the data it needs to create the underlying accounts. Being based on OAuth, this would require far less integration than the SPML based approach would.

Mapping the concepts, the RPs Provisioning Service becomes the OAuth Consumer, while the IdPs Provisioning Service becomes the OAuth Service Provider. The interactions are outlined in the diagram below (greatly simplified for the purposes of this discussion).

The Challenge

But when you look at the actors involved in OAuth, you run into one problem – OAuth was defined with users in mind, not enterprises. So you find the User as part of the protocol, but nothing that would allow the Enterprise to have a say in the exchange. And this raises an interesting challenge.

Just like there are security issues to resolve in the OpenID protocol for it to satisfy enterprise requirements, there are policy challenges that would need to be resolved in the OAuth exchange as well. Connecting the services only requires that the user in the flow provide their assent, but if OAuth were to step in as a federated provisioning protocol, it would require some way for the enterprise to inject (fine-grained) business policy into the exchange. And what if approval workflow needs to enter the picture?

One thought would be to introduce an IGF style declarative policy mechanism that would allow the services on each side of the exchange to declare intent and policy, thereby allowing some automated decision making that ensures that security and business policies are honored by the exchange. Because when you are talking about fed-prov, a one-size-fits-all construct will be a non-starter.

My posting on twitter did generate some good feedback from folks like Eve Maler and Ashish Jain. I am interested to get people’s thoughts on the viability of this idea, and whether you think adding OAuth to provisioning systems would be part of the move to enabling enterprise identity management systems for the cloud.

Tags: Cloud Computing, Cloud Identity Model, Federated Provisioning, OAuth, SPML