Fed-Prov and the Cloud: JIT Provisioning to the Rescue?

In my last post, I talked about Advance Provisioning, and how it was problematic in the cloud world because of the integration work and pre-defined business relationships (at an IT level) it requires. A lot of the appeal in using and delivering cloud-based services is the ability to enable short-lived and limited-use business relationships (case 3 I described in the previous post), and advance provisioning is just not suited for this. So, can Just-In-Time Provisioning help here?

Just-In-Time Provisioning Described

JIT Provisioning is a far more dynamic model to approaching the federated provisioning problem. This, when combined with standards-based interactions, can provide a light-touch provisioning approach far more suited to the Cloud. The architectural model would be as follows:

• Steps 1 & 2: The user arrives at the cloud service (RP) with an AuthN token containing claims
• Step 3: The RPs federation service can recognize that the incoming user has never used the service previously and therefore does not have an account within the local account store. At that point, the federation service can alter the usual flow (which would be to log the user in transparently and let them access the service), and instead extract the data from the claims and send it to the provisioning service along with a request to create an account.
• Step 4: The provisioning service would check policy and if it passes, create an account in the account store, and return a success response to the federation service – all synchronously.
• Step 5: The federation service can now go ahead and log the user in as it normally would.

This is a pretty well understood and clean flow. In fact, SAML (with the SSO Profile) and OpenID both define support for this use case and are considered de-facto JIT Provisioning protocols. And most cloud service federated provisioning use cases would be solved with this approach.

Notice though that I said “most” and not “all”. And this is where the real enterprise-grade problems come in.

Problem 1: The Integration/Standard Problem

With such a clean flow and well established protocols like SAML, you would think that there would be a lot of implementations for this. But that is not the case. There are a number of OpenID implementations that do this, but that is only when everything in that cloud on the right is one application that handles all aspects of it. However, in the enterprise, the federation and the provisioning responsibilities are externalized from the business application into their own components. And this is where the challenge comes in.

While the token exchange part is well defined and standardized, the interaction between the federation service and the provisioning service is not. So enterprises that have tackled JIT Provisioning have been forced to build custom integrations between those two services, something that becomes a real challenge and burden. It creates vendor lock-in, and blocks the ability to upgrade or enhance the services. So what is really needed is an effort to standardize the channel between the federation service and the provisioning service.

One approach would be to allow the federation service to use a SAML token as the data element within an SPML request. I know work was started (but never completed) on a SAML Profile for SPML, but as Jeff points out, the design center for that was actually Advance Provisioning, not JIT Provisioning. Another possibility would be for the provisioning service to accept SAML tokens directly, but then there would be a need to enhance SAML to introduce provisioning operations into it (something that is being asked for and discussed under the moniker SAML Subject Management Protocol, I believe).

Problem 2: The Feedback Loop

Another problem is that there is no feedback from the cloud service to the enterprise regarding what happened with respect to account creation. How can the enterprise know whether an account was created or not, what the nature (entitlements, etc) of the account is, and other pertinent information. Most enterprises want to know this so that they can (a) track this for audit, attestation and general compliance reasons and (b) use this to issue update and de-provisioning requests (a whole other area solvable in the Advanced Provisioning model, but unaddressed in the JIT Provisioning model.

Problem 3: The Data Problem

A fairly thorny issue is the data problem. The JIT-Prov flow above assumes that the federation service obtained from the claims within the token all the data that the provisioning service needed to do its job. This is actually not a practical assumption to make in a lot of enterprise cases. Provisioning usually requires a lot of profile data (data like profile attributes, roles, entitlements, etc) to create accounts in applications, especially COTS applications. Just look at the data forms that ship with connectors for SAP or even Exchange. While all of that data is not necessarily needed in all these applications, the fact is that a lot of applications being moved to the cloud need it today anyway. And the more interesting applications (like CRM, Helpdesk, etc) need a lot of user data to be in their store for operational purposes. Again, I am not (in this series) commenting on whether this is correct or not, since my focus is on getting things to work the way the business needs it.

So, what do we do? You don’t want to bloat the AuthN token with all this data unnecessarily every time you send it across to the RP, on the off-chance that provisioning may be needed. In any case, how does the IdP even know what data to send (on a per cloud service basis)?

Now, one possibility is that when the IdP is issuing the SAML token, it can detect whether this user has an account at the cloud service or not (in the absence of the feedback loop mentioned in the previous problem, this would be guesswork based on whether a token has ever been issued previously for this service – you can see the issue here). If it detects that an account doesn’t exist, then it could add the additional claims needed for provisioning in that case only. So while the IdP usually sends over X claims in the SAML token, it could now send over X+Y claims. This is definitely a viable solution, but suffers from two issues:

• The feedback loop challenge, as I mentioned.
• More importantly, how does it know what specific claims the cloud service needs for provisioning? It cannot assume a fixed set for all services and send all of it, as that would end up in it always sending a superset, which violates the minimal disclosure principle.

So, how can we support discovery, data retrieval and policy enforcement while still keeping the JIT Provisioning model (relatively) simple? Well, there are a few architectural options that I would like to throw out there in the next post.

[Ends Part 3 of 4]