On Wednesday, I gave a talk entitled “Beyond SPML: Access Provisioning in a Services World” which built on my Gluecon talk and work with Fusion architecture to provide a vision for the future of provisioning. The central thesis is that as we move from Push to Pull models in Identity, provisioning becomes a key component in making sure that policy and process controls are still enforced. But this requires a fundamental evolution in application and middleware architecture towards services-oriented security and externalized identity.

I was extremely gratified to receive lots of positive validation and feedback about the vision I expressed in my presentation. And it really fit in with the theme flowing through the presentations in the provisioning section, which was focused on moving to a more streamlined, manageable, scalable provisioning future. It also echoed sentiment that provisioning is a multi-faceted problem with different interaction points and flows and will therefore require a combination of standards rather than just one standard. This was really driven home by the extremely interactive SPML SIG meeting that I participated in (organized by Mark Diodati) where there was generally agreement that SPML needs to get really focused on specific use cases rather than trying to be all things to all possibilities.

I am looking  for input, so check out the deck and leave me comments on this post. I will definitely be building on the ideas in there with our identity management team to move the vision of service-oriented security forward. But for it to be useful, it has to resonate with the IdM and application development communities. And that’s where we all have to work together in making this a reality.

Tags: Burton Catalyst Conference, Cat10, Federated Provisioning, Provisioning, SPML

Option 1: OpenID Attribute Exchange

Some view provisioning as being little more than an attribute exchange. So it is natural to consider OpenID Attribute Exchange, which allows the federation service to request additional attributes from the OpenID Provider during the authentication flow. Essentially, when the federation service detects that the user doesn’t have an account, it could validate the claims it received as part of the token, and if it needs additional data, then it could add a request for those to its authentication request.

This can solve the data retrieval challenge, and squarely positions OpenID as a JIT Provisioning protocol. But the componentized architecture we have been assuming does face some other problems that it must solve in the enterprise cloud context. These are not problems with OpenID itself, rather with the overall architecture (again, this disappears when all 3 components are combined into a single service application, which is how OpenID-based RPs are able to do this today).

As discussed previously, when the SP is hosting more than one service, you often find that the attributes needed for provisioning depend on which service the user is trying to get access to. This means that the federation service would need to ask the OP for different attributes depending on which cloud service the user is trying to reach. Since the federation service can no longer just work off a static list of attributes that it should always query for, this adds the need for the federation service to able to ask the provisioning service for the list of attributes it needs, in the context of the specific service being provisioned. While the SchemaRequest operation in SPML could be used here, there needs to be a way to differentiate (in a standard way) the complete schema supported for the target by the provisioning system from that subset needed to create an account.

Another challenge created is for subsequent first interactions of the user with the other services hosted at the same SP. Since the provisioning system already knows the user, it already has some of the attributes it needs, but not all. So when the federation service queries it for which attributes it needs to retrieve, it should reply with just those attributes it doesn’t already have (from provisioning the user to a different service). The SchemaRequest operation cannot handle this scenario currently.

The bigger enterprise challenge is how the work on the OP side can be broken up between the OP (federation service) and the provisioning engine (policy and GRC service).

These are minor challenges to be sure (since you can always just get the full schema and update attributes that have changed to maintain consistency), but ones that become important when the flows are examined for compliance and consistency.

Option 2: SAML Attribute Query

In the last post, I mentioned how SAML (with the SSO Profile) and OpenID are both squarely positioned to handle the majority of the basic JIT Provisioning use cases. Good thing is, the SAML folks have been thinking about the attribute exchange problem as well, and in the spec have defined a mechanism to handle this called the SAML Attribute Query, which takes a different approach from the OpenID solution. The query for attributes in this case can go over what they call a back-channel. This can be leveraged to facilitate an attribute exchange between the Provisioning Services on each side of the federation boundary.

The big advantage of this model is that the front-channel (usually the browser, but could be other environments much harder to manipulate) is not getting overloaded with the data retrieval task. Also, since the two provisioning systems are talking to each other, they are fully aware of what is going on and can enforce standard provisioning policies as well as track and audit the happenings on the other side – major considerations in the enterprise space.

However, this does mean that it isn’t truly on-the-fly, since the SAML spec would require that a trust relationship be defined between the two sides ahead of time. There is actually a lot of interesting work being discussed right now in the SSTC that could directly influence fed-prov use cases, so I would encourage folks to keep an eye on that.

Option 3: OAuth + ArisID (IGF)

Last (but not least) is a possible solution that I first contemplated on my blog a few months ago, and have since been noodling over with other folks, and that is the thought of leveraging two emerging powerhouses – OAuth and the Identity Governance Framework. The idea here is very simple. When the user first goes to the SP, the SP can initiate the creation of an OAuth connection with the enterprise provisioning engine, facilitated by the user, of course (this is, after all, a user-centric protocol). The enterprise, for its part, can put in place policies and risk-based controls that would allow it to trust such a connection. With the connection between the parties established, the SP provisioning service can now use the ArisID APIs being defined as part of the IGF work to retrieve the data it needs. IGF adds a whole policy layer here, since the SP will provide a CARML declaration regarding itself (for instance, including details of its SAS 70 certification), the attributes it needs, and how it intends to use them (emailing user policies, storage policies, etc). The enterprise provisioning engine for its part can evaluate the CARML file and publish it’s own AAPML file with its policies.

One of the interesting things about this approach is that it enables the creation of on-the-fly trust between the two sides. The enterprise may never have dealt with this SP before, but can still interact with it with a certain level of trust. This trust is built on two separate components – the assertion from the user itself asking that provisioning take place (OAuth flow), and the CARML file declarations (IGF flow) – that make the creation of the federation a risk-based decision (automate-able) as opposed to a business decision (manual). Since this model also involves the provisioning engines on both sides, the security and policy controls can be enforced.

Still Work To Be Done

These models obviously need to be explored and poked at in depth to determine if they hold. And while these depend on some standards work that is still to be baked, there is a lot of other standards work happening (in particular in the OpenID and OAuth arenas) that could supplant these options completely.

And there are major lifecycle management issues still to be discussed and explored. How does one handle de-provisioning in a JIT Provisioning environment? How can SPs that want to know about profile updates find out outside of the user interaction? And how do all those workflow and policy based controls that are present in Provisioning systems today fit into all of this? Well, I will be exploring some of this in my Burton Catalyst North America talk on “Beyond SPML: Access Provisioning in a Services World” in July. So be sure to check out that session if you’ll be there. In the meantime, please keep leave your comments and feedback here so we can keep the discussion going.

[Ends Part 4 of 4]

Tags: Attribute Exchange, Cloud Computing, Federated Provisioning, Gluecon, GlueCon-FPSeries, Identity Governance Framework, IGF, JIT Provisioning, OAuth, OpenID, SAML

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]

Tags: Cloud Computing, Federated Provisioning, Gluecon, GlueCon-FPSeries, JIT Provisioning, Just-In-Time Provisioning

In my last post, I laid out the case for why federated provisioning is important for the cloud. Now let’s look at a deeper look at Advance Provisioning and it’s suitability for the cloud.

Advance Provisioning is pretty much the same as our classic understanding of user provisioning. It usually involves user accounts getting managed in batch mode through data file (XLS, LDIF or CSV) exchange or via connectors. I do want to point out that it is not just bulk provisioning, as Jeff Bohren suggests, since it supports ad-hoc individual account creation in response to requests for access users make in their Helpdesk, Ticketing or Provisioning system or triggered by policy events like hiring, promotions, etc (Whether you want to do that or not would be, as Jeff points out in another context, a business decision).

Enterprise’s Love Advance Provisioning

Now, enterprises are pretty comfortable with the idea of advance provisioning, precisely because of that similarity it has to classic user provisioning. They understand it and the implications of it for their business and security practices. It fits in with the existing policies and controls that they have spent years designing, perfecting and deploying solutions for. And it can handle the entirety of the provisioning lifecycle, including updates and de-provisioning of access.

But It’s A Little Too Like Classic Provisioning

But advance provisioning also brings with it the same baggage that classic provisioning has, namely the integration burden. Even when you add a standard like SPML into the picture, deployments are pretty hard. That’s because SPML is the most non-standardized of standards, with no two target system implementations being alike.

And when we start digging deeper into some of the scenarios that enterprises are dealing with, we find that SPML doesn’t even begin to address some of the issues being faced. For instance, a number of enterprises in a federation environment are actually exposing multiple services to their partners. These enterprises want all those federated provisioning interactions funneled through their provisioning engines (for the obvious security and compliance reasons), and SPML can’t handle the pass-through granularity required in these use cases. For instance, in the diagram below, the provisioning engine on the left has no way of asking the provisioning engine on the right to create an account for a user on service 2 (out of the 3) only. The only way to handle that currently is through an agreed upon role/attribute-based convention. This is clearly not manageable in cloud environments.

Here Comes the Cloud

When we consider advance provisioning in the context of managing cloud services, we see that the cloud model exacerbates all these issues. I have been saying for a while that cloud computing is hugely disruptive for traditional enterprise IdM. The way in which the cloud is changing how enterprise users do business is creating huge issues for advance provisioning. Let’s look at 3 advance provisioning scenarios (illustrated in the diagram below):

• Case 1: If you are an enterprise that is partnering with a large service provider, e.g. Fidelity, to handle employee 401Ks or stock programs, it is worth your while to build an SPML or proprietary API based provisioning connector to the Fidelity services. That’s because of the strategic nature of the partnership and the volume and importance of provisioning you will be doing (current and past employees).
• Case 2: If you are an enterprise that is leveraging the services of a major cloud-based service provider like Google Apps and Salesforce, then having connectors that are based on their proprietary APIs can be justified to the business, again because of the strategic importance and transactional volume of those services (In fact, those two are probably the most requested connectors for cloud services our customer base is asking us to deliver).
• Case 3: But take the scenario where you are an enterprise with a small marketing team. The team wants to use the cloud-based service of a small vendor for a year or so as part of a local promotion campaign they are running. Here, you see the limitations of the advance provisioning approach. Most of these cloud services were put up pretty quickly and have no provisioning APIs to speak of. If they do, they usually aren’t standardized. And the Enterprise’s IT department is not going to invest in building a connector to this service, since it is short-lived and of low use.

So what we are seeing is that the advantages of the cloud – namely the agility and flexibility it gives business to get work done – is facing a significant barrier to adoption because it cannot be managed by current enterprise infrastructure. And this opens up serious security risks, because these small teams that have their livelihood riding on successfully doing their job will just figure out how to get around the security and policy restrictions and controls ([update] read this for some interesting, and relevant survey analysis [/update]). The important thing to recognize here is that case 3 above is not the outlier, it is actually the majority use case, since this is where the real value found from the cloud model is.

One Solution: SPML Gateways

Of course, the ideal solution here is for these SPs to support externalized identity providers, or leverage provisioning services that are part of the platform they are built on. This is the Service-Oriented Security vision that we have been promoting at Oracle. But as I explained before, for a lot of these SPs their services are not newly built applications, but transplanted applications that they can’t afford to re-engineer for this new architectural paradigm.

So, one of the possible solutions here would be to develop a way for these small cloud-based SPs to deploy a lightweight SPML-based provisioning service in front of their offerings, essentially providing an API abstraction for provisioning to these services. The SP could quickly integrate this service with their business service’s underlying identity infrastructure, and their enterprise customers can quickly enable connectivity to this service in their provisioning environments.

But this is still not a perfect solution, because this still carries the integration burden, and demands that these federations be defined up-front as an enterprise-to-enterprise decision, something that is problematic in the dynamic, on-demand nature of the cloud. So what to do? Stay tuned.

[Ends Part 2 of 4]

Tags: Advance Provisioning, Cloud Computing, Federated Provisioning, Gluecon, GlueCon-FPSeries

I was there as part of a strong and vocal contingent of identity folks. It’s important to remember that identity is not just a security concern for the cloud, but a business enabler as well, having the potential to smooth adoption of services and ease integration between different cloud services. In this way, identity really can be the glue for the cloud (or the lube, as Doug Crockford called it, when he loudly rebranded the conference “LoobCon”).

It was pretty cool for me to be part of the “Hacking Identity” session that included Eve Maler talking about UMA, Chris Messina talking about XAuth and Brad Fitzpatrick talking about Webfinger. My topic stuck out a little like a sore thumb in there, because Federated Provisioning hardly has the same potential as a game-changing technology. But as I laid out in my talk, it is very much a concern in the near term for Enterprises that are looking to leverage cloud computing through a re-factoring (as opposed to a re-architecting approach). Below is the deck from my talk.

The content is a little dense to explain adequately in a deck, and since I couldn’t really record the voiceover, I think I am going to explain the content in a series of blog posts. So consider this part 1, the introduction.

Why Federated Provisioning Is Important To The Cloud

A lot of the talk in the new architecture of identity management is about externalizing identity from applications and services. I’ve certainly talked about it a lot on this blog, and it is at the heart of the Service-Oriented Security model that Oracle has been promoting. But for many enterprises, moving to the cloud is all about taking existing applications that they have and moving them to the cloud without re-architecting or re-engineering them, so that they can start getting incremental benefits from the cloud movement. This means that there are going to be a ton of services in the cloud that have their own little identity silos that will need to be managed; in other words, provisioned.

Also, provisioning tools are at the heart of any Enterprise’s identity GRC solution. Enterprise’s have spent a lot of time and money defining policy and workflow based controls that provide them both security and regulatory compliance. And they don’t have the ability to just throw all that out. So being able to continue to leverage those investments in their incremental move to the cloud is also important.

And this is where federated provisioning comes in. Because in order to leverage the cloud for these services, the user provisioning of these services has to mimic the dynamic, highly automated nature of the cloud. It has to be built on standards, be light-touch and loosely coupled, and it has to just work (at scale). In a previous set of blog posts, triggered by Ian’s famous “There is no such thing as Federated Provisioning” post, I brought out that there are two kinds of federated provisioning – Advance Provisioning and Just-In-Time Provisioning.

In the following series of posts, we will look at what these two models mean for the cloud, and some possible paths to achieving solutions to the problem.

[Ends Part 1 of 4]

Tags: Cloud Computing, Federated Provisioning, Gluecon, GlueCon-FPSeries

First up is the European Identity Conference in Munich from May 4-7. Kuppinger Cole does a good job putting together an interesting agenda with a broad array of speakers and a lot of local perspective, something those of us from across the pond don’t always get the opportunity to share. I’m lucky enough to be slated for 2 panels, one on Identity GRC as an evolution of User Provisioning, and the other on the need for Identity Standards as the foundation for Cloud Security. The Cloud theme is pervasive, especially since this is co-located with the Cloud 2010 conference.

The middle of the month brings us the 1H edition of Internet Identity Workshop (May 17-19 at the Computer History Museum in MountainView, CA). This is always a great place to exchange ideas and really plug into some of the brainpower that exists in our industry. I’m really hoping I can figure out a way to spend some time there and keep my finger on the pulse of the user-centric identity community.

At the end of the month (May 26-27 in Denver, CO) is Gluecon, a conference organized by our old friend Eric Norlin, that is focused on “the bits and pieces, APIs and meta-data, standards and connectors that will help us to glue together the varying applications of a post-cloud world.” Looking at the agenda, you can see that it is far more technical than your usual industry conference, and it has a great lineup of speakers. I will be speaking on the topic of Federated Provisioning, an often forgotten but critical component of security in your cloud environment. Hurry up and register, because early-bird registration ends this Friday — and you can use code spkr12 for an extra 10% off.

Here’s hoping I can get through May gathering some inspiration and without getting exhausted. Should be very interesting.

(UPDATE: Details added to my Speaking page)

Tags: Cloud Computing, European Identity Conference, Federated Provisioning, Gluecon, Identity Governance, Identity GRC, IdM Standards, IIW, Internet Identity Workshop

One of the topics that has been fodder for some animated discussion has been the topic of federated provisioning. As the cloud has brought federated authentication back into focus, it has also shone a light on the need for federated provisioning to power cloud identity. After a very interesting discussion that I had with some folks who are looking at identity in the cloud, I posed the following question on Twitter:

Had an interesting discussion this morning on how OAuth could be to federated provisioning what OpenID is to federated SSO. Any takers?

The Thesis

Federated provisioning is about creating an account with appropriate privileges in underlying systems on the Relying Party side when triggered by an authentication event (user comes to the RP service from the Identity Provider, or IdP, side). Further, the authentication token being presented to the RP does not contain sufficient claims (attributes, etc) for the systems on the RP side to create the necessary account (there are other scenarios, of course, but this is the common one I am trying to address). Consequently, we have a need for the RP to get provisioned with data from the IdP side.

Now in my post “The Thing About Federated Provisioning“, I pointed out that there are challenges in doing all of this just-in-time. Enterprises often resort to out-of-band pre-provisioning of accounts across the domain boundaries, which is where SPML proves to be adequate. But the demand for JIT mechanisms still exists. The cloud exacerbates this problem greatly, because pre-provisioning is pretty much impossible when you move up to the scale and loose coupling of the cloud. And the nature of SPML requires that extensive integration be done before the connection between the RP and the IdP can go live.

And this is where I believe OAuth could play a role. OpenID is already viewed as a lightweight solution for enabling federated authentication, with attribute exchange supporting the simpler data transport scenarios. We could now augment this flow by adding an OAuth-based data provisioning mechanism that allows a Provisioning Service on the RP side to connect back to a Provisioning Service on the IdP side and retrieve the data it needs to create the underlying accounts. Being based on OAuth, this would require far less integration than the SPML based approach would.

Mapping the concepts, the RPs Provisioning Service becomes the OAuth Consumer, while the IdPs Provisioning Service becomes the OAuth Service Provider. The interactions are outlined in the diagram below (greatly simplified for the purposes of this discussion).

The Challenge

But when you look at the actors involved in OAuth, you run into one problem – OAuth was defined with users in mind, not enterprises. So you find the User as part of the protocol, but nothing that would allow the Enterprise to have a say in the exchange. And this raises an interesting challenge.

Just like there are security issues to resolve in the OpenID protocol for it to satisfy enterprise requirements, there are policy challenges that would need to be resolved in the OAuth exchange as well. Connecting the services only requires that the user in the flow provide their assent, but if OAuth were to step in as a federated provisioning protocol, it would require some way for the enterprise to inject (fine-grained) business policy into the exchange. And what if approval workflow needs to enter the picture?

One thought would be to introduce an IGF style declarative policy mechanism that would allow the services on each side of the exchange to declare intent and policy, thereby allowing some automated decision making that ensures that security and business policies are honored by the exchange. Because when you are talking about fed-prov, a one-size-fits-all construct will be a non-starter.

My posting on twitter did generate some good feedback from folks like Eve Maler and Ashish Jain. I am interested to get people’s thoughts on the viability of this idea, and whether you think adding OAuth to provisioning systems would be part of the move to enabling enterprise identity management systems for the cloud.

Tags: Cloud Computing, Cloud Identity Model, Federated Provisioning, OAuth, SPML

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…”

Tags: Federated Provisioning, Provisioning

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?).

Tags: Federated Provisioning, Provisioning