Can OAuth do what SPML hasn’t?
I spent an interesting week at HQ last week, trying to deal with some of the craziness that occurs every time a major release is on its way. But far more interesting were all the identity management conversations I engaged in during the course of the week – in hallways, over meals and especially over drinks. Suffice to say that it was a very thought provoking week. I wanted to use this forum to expand on a conversation that started in one venue, and then spilled over into the Twitterverse.
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?
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).
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.
(Thanks for the namecheck! 🙂 Interesting… So I'm guessing you'd have a (perhaps truly RESTful) SPML-ish interface offered by the provisioning service on the IdP's side, and the provisioning service on the RP's side authenticates to the other side in (two-legged?) OAuth fashion before making its data requests. OAuth provides the authenticated-request substrate, but (as is the case in other uses of OAuth) the responding side would still have to publish its API for doing application-level stuff.
(For the intent-and-policy requirement, maybe IGF in combination with an enterprise-friendly UMA could someday fill the bill. 🙂
Why not just include the appropriate attributes for JIT Provisioning in the SAML Assertion during federated SSO?, these attributes are set by the IDP Any need for out of band or pre-provisioning can be done with SPML. In my opinion, the user centric identity assertion stuff like OpenID and Cardspace hasn't really gained any traction (maybe less than SPML has). I do like the idea of the IDP sending intent and policy to the RP (SP). Not sure if using a user provisioning product to send policy information is the right way to go.. but it's certainly worth further discussion.
We see a lot of traction around the idea of NOT having to provision the Identity to the service provider or relying party, either pre using SPML or JIT.
Why should we not use some sort of VJIT (Volatile JIT) provisoning?
Meaning the SP or RP doesn´t need to create or store the Identity, but is just able to use the provided information (assertion/attributes) in making authorization decisions, auditing the information and so on. All without storing the Identity at the SP or RP.
Pretty much, Eve. And I do think that there are good things in both IGF and UMA that can come together in a way to make the whole thing both user- and enterprise-friendly at the same time. The big thing that needs to happen (the point of the post title) is that we (the IdM industry) need to make it easy for RPs to connect to IdPs in an enterprise grade federation.
Some of this is addressed in the other comments on this and my previous fed-prov posts. You never want to pollute the SAML assertion with all the extra attributes needed for JIT Provisioning on the off-chance that it might be needed. The SAML assertion should have minimal information. And out-of-band provisioning has faced some significant adoption challenges because of the complexity involved. My thought on OAuth usage is aimed at smoothing some of that, though not solving it completely (the SPML-like API still needs to exist, and the non standard way of using the standard is still a problem).
In an ideal world, you are right that the RP shouldn't need to create or store the identity. But this use case is aimed at those (existing) systems that enterprises are trying to open up to external domains that need internal stores to be provisioned to function. And sadly, this covers the majority of those systems.