Will the “real” federated provisioning please stand up?

Blogger: Ian Glazer

Nishant has commented on my post about federated provisioning.  He has provided two different examples of federated provisioning.  One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning.  In this case, Nishant agrees with me that provisioning of this sort is no different than provisioning the UNIX box down the hall.

But it is Nishant’s second example, the just-in-time provisioning example, which is a bit tougher.  In this case, the enterprise and its service provider have a federation in place.  Using SAML-based authentication, a new user attempts to access the service provider’s service.  The idea (hope?) is that the service provider recognizes the new user request, provisions the user, and authenticates the user in the same conversation. Nishant does add a degree of difficulty in this scenario as he ties the federation service to a provisioning service.  Grabbing attributes from the SAML token, creating a SPML message, and handing that to a provisioning service is possible, but as a commentator points out this sort of interop isn’t spec’ed out so the heavy lifting is left to the service provider.  And even if the service provider doesn’t want to directly link its federation and provisioning services, it still needs to grab that assertion attributes and create the account in the backend system. 

It turns out, to my surprise, that there are people doing this.  Parties in a federation agree to which attributes are needed and send those in their authentication assertions.  A process at relying party uses those attributes to provisioning new accounts.  This is a fairly lightweight and effective approach, but there are some catches to be aware of.

The first catch, as Nishant points out, is if the service provider needs attributes above and beyond what are in the assertion, there’s not an easy way for the service provider to ask for them.  To deal with this, the service provider has to present a registration screen of some sort to the user.  Compared to the first scenario in which the federated account is already waiting for the user, the second scenario is herky-jerky and will annoy/confuse the end user.

The second catch is deprovisioning.  The provisioning process hinges on an authentication event.  Deprovisioning cannot be activated on de-authentication.  This does leave the problem of how to remove accounts when people have left a federation partner.  In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login.  After some period of time without an authentication, the account is suspended or deleted.  Not a bad way to go.

JIT Provision may in fact be “real” federated provisioning, but not provisioning, as a dogmatic, dyed-in-the-wool provisioning guy would immediately recognize.  While I take my dogma for a walk, this quarter Lori and Bob are going to looking into some of the intersection point of identity management and SaaS and I think they’ll have more to say on this type of conversation in the coming months.

Comments

[KeithD]

I understand your worries here, but in many low risk environments you can live with them. Firstly, as long as we have federation for authentication, the ex-employee cannot get into the SP account since his employer will presumably refuse the authentication request. So you just have some old files floating around at the SP that can't be accessed. Secondly, you could agree to delete the account if unused for x months. Thirdly, you could delete on the first refusal of the IdP to authenticate the user.

The problem is that Federation and Provisioning are different beasts - stop trying to get them to breed.

[Dave S]

I agree SAML assert purely cater to authentication and adding payload of provisioning is not really scalable but a hack. Think XACML 3.0 shows more federation capability and promise.