Matt Flynn brought to my attention an article in which Dale Olds talks about the need for hosters (companies that provide the platform on which you deploy your Cloud/SaaS applications) to provide identity services (and as Matt points out, security services in general) as part of their offering.

<Side Note>No, I do not have a vendetta against Novell, though these last few blog posts may make it feel that way. I actually really like the Novell gang – Dale, Ben and Nick Nichols among others – and for the most part completely agree with their views on identity.</Side Note>

Now, I am with Dale for the first half of the article. Developers of these cloud applications just want to focus on the business logic that is at the core of their service, and not have to worry about the plumbing items, which would include identity management. This is fundamental service-oriented security principles at play, and the survey Dale mentions reflects this (I would argue that even the one-third of SaaS vendors that said they want to handle identity themselves are either saying so because they don’t know what’s involved or are just not happy with what they are getting from the platform and embeddable components). A good set of identity services goes a long way in making applications agile and more acceptable/appealing to customers.

But then the article talks about hosters using identity services as a way to make their platform sticky, because if the platform owns the user accounts for the service, then the service will be hooked. I actually envision the opposite of that when I think of identity services in the platform – identity services making it possible for the SaaS vendor to switch between platforms easily. What is being described sounds like an Identity Provider, which is a business service, not a platform service.

What the platform should provide, and what most enterprise customers would want, is an Identity Hub service, as opposed to an Identity Store service. This allows the customer of the SaaS application to plug it into their enterprise identity store (usually a corporate LDAP system, but it could also be their Salesforce user store) and also accept incoming identities over the wire, while still freeing the SaaS vendor from having to manage identities. In this model, the stickiness for the hoster comes not from owning the user accounts, but from the QoS of the identity services they are providing to their customers (the SaaS vendors and their delegated customers). It also doesn’t force a SaaS vendor to be married to one platform.

Now, I am going to be a little presumptuous here. Having spent some time with Dale, and knowing his past work, I think that he believes in the view I am taking as well. The article seems to be discussing the topic of identity services from a particular angle, which is that there is currently a market opportunity for hosters to leverage the lack of good (non-enterprise) Identity Providers to make their platforms more sticky. It is absolutely true that platforms can (and are actively seeking to) make themselves sticky by owning the accounts; Dale points out that this is exactly what Google did by leveraging GMail as the gateway drug (see, I told you the metaphor works). But as Google seeks to penetrate the enterprise market deeper, even they are recognizing the need to support federated identities as a necessary step for viability. (UPDATE: An old blog post of Dale’s actually clarifies this, and in essence agrees with the view point I am stating here – exactly as I thought he would )

Bob Blakley has long mused about what business models would make Identity Oracle’s viable. And the simple truth is that  platform players like Google or Force.com that can leverage an identity-rich business service that they also have are ideally suited to be trusted Identity Providers. But while a big platform player can certainly be a good Identity Provider, not all hosters should need to be Identity Providers to be successful. Instead, standards based identity services would be a great asset for hosters that want to be sticky (by being the best platform to deploy on) without having to take on the onerous task of being an Identity Provider (which has its own challenges) or passing on those responsibilities to their customers (which is what mostly happens today). And it would be an asset for SaaS vendors that want to have the freedom of choice that we all crave, and that want to be able to work with their customers identity infrastructure. As Dale says in the article:

You see, people can move an application from one host to another without much trouble.

Now, isn’t that a good thing, and something that we should be aiming for?

Tags: Cloud Identity Model, Identity Services, SaaS, Service-Oriented Security

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