Advance (Federated) Provisioning and the Cloud

It’s pretty gratifying that some really smart people are doing a deep-dive on the ideas I threw out there in my “Federated Provisioning and the Cloud” deck and challenging some of the ideas in there. Means that I get to tap into the brain power out there in the identity community to flesh out the concepts. And I do look forward to the rebuttal from Ian, aka “The Black Knight”.

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, which makes bringing in a managed security service provider or similar experts an important factor to consider. At the end of the day, these small teams trying to adopt the cloud have their livelihood riding on successfully doing their job. Without help, they will just figure out how to get around the security and policy restrictions and controls on their own (read this for some interesting, and relevant survey analysis). 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]