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 difficult 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.
what others say