Talking Identity

Ian Glazer recently blogged about federated provisioning, saying "Federated provisioning should not exist; there is only provisioning.". Well, I think he's both right and wrong about this. Let me explain.

Suppose two companies, Acme and Omega enter into a federation agreement, whereby employees of Acme will be able to access a service at Omega using their Acme credentials. There are two scenarios here for federated provisioning.

Scenario 1: Advance Provisioning

Acme decides that they will decide beforehand which employees are allowed to access Omegas service (based on business rules or approved requests). They will therefore do some advance work sending provisioning requests to Omega for those employees that are to have access, allowing Omega to set up federated accounts (with the appropriate mappings) for those employees. A lot of times today, this is done in the form of a batch file/spreadsheet/LDIF file containing all the users that should have access going from Acme to Omega. In an ideal situation, this would be handled by Acme's provisioning engine sending SPML-based provisioning requests to Omegas provisioning engine.

This is the scenario that Ian is referring to when he says that federated provisioning is no different than regular provisioning, and he's right. As a provisioning target, Omegas service is no different from a sensitive target within Acmes own boundary (the logistics of setting up the trust may be a little harder). And whether or not the service is SPML-enabled or not really doesn't change the problem statement.

However, there is another scenario that changes the discussion a bit.

Scenario 2: Just-In-Time Provisioning

Acme decides that they are not going to decide beforehand which employees are allowed to access Omegas service. Instead, a link to the service is available on Acmes intranet, and whenever a user decides to go to the service, they should be given an account. In this case, no pre-provisioning is taking place. Instead, the provisioning has to occur in real-time, when the user accesses the service via the intranet link for the very first time.

The idea here is that when Omegas federation server encounters the incoming SAML token for a new user, it would recognize that the user does not have a federated account, and send the SAML token to Omegas provisioning server. The provisioning server would create the account right then and there, and return the necessary result back to the federation server so that the federation server can proceed to grant the user access.

This scenario is much more complicated than scenario 1 because of multiple dimensions. First off, the interaction between the federation server and the provisioning server has to be responsive and well-defined (and to prevent vendor lock-in, standards-based). An added wrinkle may be that the federation server may need to collect additional user information not available from the SAML token, in order to provide the complete set of information necessary to provision an account to the provisioning server (an alternative could involve a handoff to the provisioning servers self-registration screens to do the same). And the provisioning server needs to be able to understand the needs of the federation server with respect to provisioning and responses. I won't even go into the need for cache invalidation, etc.

This is where federated provisioning is not like regular provisioning (as we know it today). There are a number of things needed here that regular provisioning isn't set up for. The standards-based interaction between the federation server and the provisioning server isn't defined today, and SPML is not set up to accept SAML tokens as data inputs, or handle the just-in-time nature of this scenario. This is where a lot of work still needs to be done.

I would be interested in hearing if anyone has done anything to do with scenario 2. And, of course, any dissenting opinions on the matter (Ian?).

My previous post on federated provisioning generated some interesting responses, both in the comments and in the blogosphere (see responses from Ian, Pamela and Pat Patterson). The topic has been so engaging (starting with Jackson Shaw's post) that while I was writing this post I saw that Dave Kearns has made it the topic for a series in his newsletter.

Pat's post is definitely worth a read as it describes how Liberty Alliance has proposed a solution to the thorny issue of data exchange between the two parties in the case of Scenario 2: Just-In-Time Provisioning. It sounds like an elegant solution, especially since it solves the issue Karl brings up in the comments to my post regarding not overloading the SAML assertion with extraneous information. Would love to hear if anyone knows of any issues in the solution.

Ian and Pamela also discuss the issue of federated de-provisioning, which has also been a thorny issue in federation discussions. Pam talks about being able to initiate de-provisioning when a user who should no longer have access tries to authenticate. That is certainly one way to do it. But more often than not, de-provisioning cannot be initiated during an authentication flow because the reason the user should no longer have access is that they are no longer employed at the company they got federated from. Meaning: they cannot authenticate from the RP in the first place.

What harm then, is there in a federated account sitting around if it cannot be authenticated to? Well, the answer I usually get (from customers) is that in the reality of today's systems, creating federated access to a service often involves creating some sort of account in an underlying legacy system. An account that can be authenticated to outside of the federation context, albeit only from a back-channel. While this is a scenario less likely to get abused, it is nonetheless a scenario that security audits frown upon, and that get flagged for remediation as a compliance risk.

So what to do? Ian talks about expiring accounts that have not been accessed in a while. Out-of-band de-provisioning between the RP and the SP is also a possible option, as described by Pam. That makes the overall integration between Acme and Omega a blend of Scenario 1 and 2, where federated provisioning happens just-in-time, but de-provisioning happens out-of-band (probably on a periodic basis) through a well-defined interaction. The de-provisioning can be made real-time as well, in that the provisioning server at Acme can issue a de-provisioning SPML request to the provisioning server at Omega, just like it would to any internal system, when the user is de-provisioned at Acme.

As you can see, solutions abound, and customers can choose the one that suits their needs the best. So it is pretty obvious that it is possible to solve the federated provisioning/de-provisioning problem. The issue is that none of this is standardized or formally productized in any way, and is left as an exercise for the customer to solve (Translation: Costly integration problems when different vendor products are involved). And where this issue was a costly annoyance in federation deployments between businesses, SaaS (where this whole discussion started) takes this to a whole new level, creating a barrier for adoption.

But as Pat says "Seems like that might change now..."