The central idea of the presentation was that the cloud has caused the seemingly well-understood, albeit reviled, discipline of user provisioning to splinter (SPLITTER!) into 3 different factions – the Traditionalists, the Progressives and the New Age Thinkers. You’ll have to listen to my talk to understand it in more detail, but the reviews of my talk on Twitter seemed to be “certified fresh“. While Ian Glazer pondered:

This JIT + Pull model that @NishantK proposes in a new age wrapper on a traditional core – externalized authZ fixes some problems #cis2011

I did have Paul Madsen raving:

I declare @nishantk Python theme for #cis2011 prez a success. And am reconciled to seeing it over and over for next 3 years

All in all, I think I accomplished my goal of edutaining the folks at CIS on the continued existence of user provisioning, and its future prospects. Because the account CRUD problem will continue to be a weight around the neck of enterprise cloud adoption unless we put in place the right solutions.

Tags: CIS11, CIS2011, Cloud Computing, Cloud Identity Summit, Federated Provisioning, JIT Provisioning, Just-In-Time Provisioning, Monty Python, Provisioning

The week before that, the Cloud Identity Summit (July 18-21) will once again be warming us up for Catalyst by hosting an impressive gathering of subject matter experts and thought leaders talking about the intertwined worlds of identity and the cloud. And this year, I’ll be there too, giving a talk on the future of identity provisioning (July 20 at 12:00pm). Following up on the talks I gave last year at Gluecon and at Catalyst, I’ll be bringing my cred as a provisioning expert to bear in examining if identity provisioning even has a future in the pull-based future of identity (spoiler alert: it does), and what it might look like, given recent developments in the space and advancements in cloud architectures. In an unfortunate scheduling mishap, I will be going up against Pamela Dingle’s session on identity and mobility, which I would have loved to sit in on myself. I’m sure she’ll be peppering her session with cuteness in the form of cats or cuddly toys, so I’m going to have to up the game and incorporate something bad-ass into my session, like Transformers or Angry Birds (Iron Man was so last year). Pam, you’re going down

Two weeks. Two great conferences. And me at both. So be there or be square!

Tags: Burton Catalyst Conference, Cat11, Catalyst11, CIS11, Cloud Identity Model, Cloud Identity Summit, Conference, Federated Provisioning, Gartner Catalyst Conference

By all accounts, one of the main reasons that SPML never achieved traction was that application vendors were not involved in developing or deploying the standard. The effort to standardize provisioning of accounts was driven largely by the provisioning engine vendors. The result was an unwieldy standard that nobody could figure out how to support, and which seemed to have one fatal flaw – the lack of a standardized schema for user accounts. Last year, it seemed like SPML was being put on life support.

Now, a new effort aimed at solving this most intractable of identity problems would seem to be trying a new route. It’s called Simple Cloud Identity Management, or SCIM (born at last falls IIW as Cloud LDAP). Here are some highlights from what I see:

• It has the backing of such heavyweight (cloud) application vendors as Google and Salesforce (in addition to having the folks at Ping Identity working on it)
• It is narrowly focused on CRUD (Create, Read, Update, Delete) of user accounts, supporting both user attributes and user roles (I guess calling it Simple Cloud User Management, which is what it really is, would have been a non-starter!)
• It is REST-based (obviously)
• It provides a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols

Last year, I spent a fair amount of time exploring the world of federated provisioning, and talked about the different models that needed to exist – advance/batch provisioning, JIT provisioning through SSO channel, JIT provisioning with pull from identity provider. At the time, I held the opinion that there wouldn’t be just one standard that would play in this area. SPML would still be used for batch provisioning, but the pull-based models in JIT provisioning would combine SAML/OpenID with something like the Identity Governance Framework (which itself describes a user schema based on iNetOrgPerson). Since then, what I have come to realize is that the negative baggage associated with SPML is so heavy that folks like Google and Salesforce were never going to be become proponents of it. Also, there are specific performance and behavior characteristics needed to succeed in cloud environments that would rule out a heavy standard like SPML from the start. And any standard in this space would have to be RESTful. So last month, when a CSO asked me at a conference roundtable if SPML would ever gain traction for provisioning to cloud services, I told him that my considered opinion was No. There is just too much baggage there.

Is SCIM really the answer? Only time will tell. The real challenge will be in making sure that SCIM as a standard can support all user provisioning use cases, not just a very narrow band that needs to be supplemented with proprietary schemes or other efforts. SCIM won’t succeed if administrators still have to log into the SaaS applications web interface to “finish” creating the account. Would SCIM support creating 100s of accounts in one batch command (and appropriate error messages/feedback) for that day when all the interns start at a company and need accounts provisioned? How would compliance requirements be met when there is nothing in the standard that allows to query for changes made to the account? Some of the provisioning connectors need to communicate with the target application ahead of time to determine if the changes being sent would result in SoD violations. Would SCIM provide an API for this?

And do we really want to have one standard for internal applications and a different one for cloud-based applications? The answer most definitely is NO.

I’m a little ambivalent about SCIM at this point. In my opinion, SPML just was not going to make any inroads, so a fresh approach was definitely called for. But there were efforts like IGF that could have been leveraged here instead of starting from scratch. And it will be interesting to see if a robust provisioning standard can develop from an agile effort lacking the rigor of an OASIS standards process. I’m looking forward to exploring these topics at IIW in MountainView next week (where I will be for the first day and a half). Should make for some vigorous debate.

Tags: Cloud Security, Federated Provisioning, SCIM, SPML

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