At Burton Catalyst in San Diego this year, the identity analysts framed a future of “pull” provisioning. The “pull” model for provisioning states that access is only granted (and possibly provisioned) at the time of request and that all the information necessary to model the user for the application should be “pulled” from an available source.

I love the theory and believe we as an industry should strive towards this goal, but there are a few big holes to fill…

What’s required by the application to provision a new account?

My immediate thought when I heard Bob Blakley’s presentation was that there is no way that all the necessary information can be pulled when needed. And when I say all the information, I mean identity and authorization attributes as well as compliance related artifacts such as approvals and separation-of-duty policy evaluations and identity assurance results.

Take for example a pure pull provisioning operation for a SaaS CRM solution. Imagine that I have just transferred from the Services Department to the Sales Department and I should now be able to access the SaaS CRM solution to which my company subscribes. With a purely pull model, I should be able to navigate to the CRM solution through our Federated SSO solution and instantly get access without any obvious “provisioning” operations occurring.  For our CRM system, and actual account needs to be created.. much like the most popular online CRM solution.

How would this work?

Request:

When I navigate to the CRM solution, the federated access management solution redirects me to my IDP to authenticate me and sprinkle some attributes (assertions) on my token and then redirect me back to the CRM site.  It would recognize that I have never been to the site before, and proceed with provisioning operations.

Gather:

Here’s where the interesting part starts to happen. What information is needed by the CRM system to create an account and authorize me throughout my session?  Looking at the illustration below, the majority of the information could be gathered from the Identity Provider (IDP) through federation services and could be pre-populated on the a SAML token.  Other information, like enterprise roles, might need to be gathered from another source, either directly or via the IDP attribute service.  Lastly, there is some information that might only be known by the user, and this could be gathered at during the first request for access. (I know that authentication Q&A are antiquated, but a number of sites that support federation or OpenID still ask). Notice that for items like first name and last name, there could be different sources and different values. Also notice that some attributes will require attribute mapping (email -> emailAddress) or attribute value transformation (“CRM Admin” -> “Admin”)

“Provision”:

At this point, the orchestration of required attributes has been completed, and the actual creation of the my user account can commence.  But how, and by what service?  Looking at Ping’s solution (p.252) for provisioning, as well as Symplified’s, they both perform “last-mile” provisioning operations on the SP similar to any connector framework.  To accomplish this, there must be pre-arrangement through the definition of a target (LDAP or Database), and schema mappings from the source of information (SAML assertions or othewise) to the application. This sure looks an awful lot like how we used to configure adapters in Sun IDM… just with fewer supported target applications.  Also, notice that I put “Provision” in quotes… I’ve always said that provisioning = process, and there’s a fair amount of process missing in this scenario.  I’ll cover that in a future post.

Audit?:

Bob Blakley states that each actor in the orchestration will audit the changes that occur… This seems like a loosely traceable audit trail. (I’ll cover this more in a later post)

Conclusion:

You can see from my simple description of attribute sourcing (and Nishant’s better description) that there will be significant configuration needed to establish federation relationships, attribute sourcing, attribute translation, and provisioning targets with schemas.  Today, these configurations would need to be established for each environment and even with the use of a bag of standards, be fairly complex.

In future posts I will expand on this post and discuss the complexities of implementation, and the lack of compliance related activities.