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

I wasn’t quite sure what the first panel, “The Next Step of User Provisioning: Identity GRC as a Natural Evolution” was going to be about. On the surface, I thought it was a fairly obvious discussion topic, since the Oracle Identity Manager product has pretty much seen this evolution in it’s lifetime, where provisioning deployments went from being about IT efficiency to supporting compliance activities like attestation and reporting. Heck, back in the Thor days, we had an offering called Xellerate Audit and Compliance Manager that supported the model of building up the “Who-has-What” identity warehouse first so you could roll out attestion and compliance reporting before embarking on an automated provisioning and de-provisioning path. But our moderator John Hermans (KPMG) really wanted to make the panel interesting, challenging me and the other folks on the panel to a discussion on the value and effectiveness of Identity GRC projects. I think the point that came across consistently was the fact that the new Identity Governance products (like OIA) have evolved as business tools, not IT tools, serving as a way to give enterprises greater visibility into the state and risk of their identity environments. Beyond that, the panel is kind of a blur.

My next panel – on “Private, Hybrid, Public – Which Cloud for What?” – was a far more tame affair by contrast. And the main point I made on the panel was that the choice between the different cloud models is being guided right now by the one word that distinguishes these models from the customer perspective – Control. With a private cloud, an enterprise feels like it has more control over the infrastructure and the risks associated with it, because they have visibility into how it operates and what it is built on. Public clouds today are more opaque than transparent when it comes to their inner workings, and this is a function of the lack of standardization in the identity, security and audit functionality that the cloud services are built on. This divorces the policies and controls that enterprises have developed over the last many years from the cloud services, making it nearly impossible for the more risk-averse enterprises to consider these as viable options. This point came across repeatedly during the conference as I talked to customers and enterprises considering cloud services. Maybe it is a function of the data privacy and protection environment in Europe, but there was far greater mindshare for the idea of building identity services in a private cloud, which you could then connect via federation and service-oriented security to public cloud services.

My last panel on “What the Identity Industry should do to Improve Security for the Cloud” really focused on the idea of standards and adoption of development frameworks for consistent identity inclusion into applications and platforms. And it built on the discussion from my previous panel, as we discussed why it was that cloud vendors have not been able to create more transparency into their offerings. One of the points I focused on was that it isn’t really the cloud vendors fault that they are more opaque than transparent. Often, they can’t provide more visibility because they themselves don’t have that information. And this is a function of how these cloud services are being built, and the lack of tooling they need. We need to make it easier and more transparent for developers to build identity-aware applications. It was very interesting to hear Dr. Barbara Mandl of Daimler talk about their adoption of cloud services as an outgrowth of their adoption of the ASP vision from years ago. The result is that they had put in place a development framework for their applications that was serving them well in adopting cloud services. But she also made the point that the standards are just not mature enough or standardized enough to make this seamless and pain-free, even in areas where we (the identity industry) think we did a good job, like SAML.

A lot of what I said on the panels came together rather nicely in an interview I gave later that day to Felix Gaehtgens of Kuppinger Cole, where we discussed the challenges in identity-enabling the cloud environment, and what Oracle’s approach to this is, both from an identity management perspective and from a platform perspective. Check out the video if you have some time.

Tags: Cloud Computing, EIC10, EIC2010, European Identity Conference, Identity Governance, Identity GRC, IdM Standards

• The Next Step of User Provisioning: Identity GRC as a Natural Evolution
  • 10:30-11:30
  • Room: Galaxis
• Private, Hybrid, Public – Which Cloud for What?
  • 11:30-12:30
  • Room: Helios
• What the Identity Industry Should do to Improve Security for the Cloud
  • 14:00-15:00
  • Room: Helios

And Oracle VP of Product Management John Aisien will be giving a keynote as well on Wednesday on “Extending the Principles of Service-Oriented Security to Cloud Computing”.

So if you see me around the conference, or in the Expo area (where you can also meet the fine folks from our Oracle EMEA team), be sure to stop me for a quick chat. Unless you see me dashing down the hall from Galaxis to Helios, in which case don’t bother unless you want to get bowled over.

Tags: Cloud Computing, European Identity Conference, Identity Governance, Identity GRC, IdM Standards

In the podcast, we cover

• What are the key security concerns about cloud computing
• How security requirements vary between Private and Public Cloud models
• Key IdM technologies for securing the Cloud
• The relevance of Service-Oriented Security to the Cloud
• Best practices for approach Cloud Security
• Open standards for the Cloud

And if you’re interested in learning more about Oracle security products, sign up for the newly launched Security Inside Out newsletter, focused on identity management and security topics and products.

Tags: Cloud Computing, Identity Services, Podcast, Service-Oriented Security

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

Unfortunate coincidences on the title aside, the overall response to my session was quite positive, especially from folks whose opinions I really respect like Bob Blakley and Lori Rowland from the Burton Group. There was general agreement that widespread adoption of Cloud Computing is going to be a major disruption on the existing evolutionary path that Identity Management has been following. And adoption of the Identity Services model is a major component to readying IdM for the Cloud.

Check out the screencast (slides with audio of the session) of my session below. Registered attendees of OpenWorld can download the presentation itself and the MP3 audio recording of the session from OpenWorld On-Demand (just login with the Username and Password you created during your OOW registration).

The audio includes the questions that were asked of me, and turns out that the questions didn’t record well and I forgot to repeat them. Hopefully my answers are cogent enough that you get an idea of what questions were asked. I did want to follow up here on this blog post a few of those answers:

• A question came up regarding the licensing terms for Oracle IdM products when they are being used in a cloud environment (specifically, by organizations that are going to be Cloud Providers of Identity Services). The biggest challenge for such organizations is that they cannot accurately estimate the number of users, or other such variables licensing is typically based on, beforehand, which creates uncertainty for them as to the cost they will have to bear. After the session, I confirmed with our PM team that there is special licensing available for ISVs. Talk to your Oracle sales rep about this if interested.
• Another question came up regarding the impact of all this on standards like SPML. I believe my answer covered my opinion on the greater emphasis the cloud identity model will put on the evolution of these standards, especially SPML, which has been languishing. Follow up conversations with some of the original architects of the SPML standard and others involved in standards efforts brought up that the communities responsible for these standards are looking at this very hard and are gearing up efforts to address this. So stay tuned for more on that.
• A question was asked regarding Just-In-Time Deprovisioning of access to cloud-based assets. This is something I discussed quite a bit in a blog conversation with folks like Ian Glazer and Pam Dingle a while back. So check out that post and the related thread.

Tags: Cloud Computing, Cloud Identity Model, Identity Services, OOW09, Oracle OpenWorld, Oracle_IDM