Blog post

How do you capitalize the “P” in federated provisioning – or – The Black Knight Always Triumphs

By Ian Glazer | June 03, 2010 | 0 Comments

Last week, Oracle’s Nishant Kaushik compressed a lot of thought into a very short presentation on federated provisioning and the cloud. Not only did he summarize challenges of federated provisioning, he also proposed 3 alternatives to dealing with it. And he also managed to give me a good-hearted drubbing in the process. Go check out his presentation and come here when you are done. I’ll wait.



Nishant references an old blog post of mine in which I said there really ought not to be a concept federated provisioning, there should only be provisioning. I realize now that in that post I was confusing two concepts and wasn’t aware of it. This confusion is one that we have seen played out amongst out customers. In fact, Lori has been researching some of the problems related to this confusion. She and I will be putting her findings on stage at both upcoming Catalysts.

What I confused, and what enterprises and vendors often confuse, was Provisioning with provisioning. Little “p” provisioning is the process by which the changes to a user account are made in a managed system. This includes account creation, suspension, and deletion as well as modification to all of its attributes including group/role membership and password. Little “p” provisioning is a fulfillment mechanism.

Big “P” Provisioning is much more complicated affair. It includes access policy management which helps determine what people can and cannot actual have. It includes other identity and access governance functions such as access certification. Big “P” Provisioning is the grand vision of identity management in the enterprise and little “p” provisioning can only deliver a portion of that grand vision.

I was right back when I said there ought not to be federated provisioning. An enterprise cannot support and does not want both federated Provisioning and Provisioning. Having two different access policy and compliance tools is a non-starter. Considering access certification – regardless of where a system resides, a SOX-sensititve system is a SOX-sensititve system. Enterprises want all of their SOX-related access certifications in a single system and a single process. But entitlement discovery from cloud-based applications is by no means a solved problem which means that identity and access governance for cloud application is not a solved problem. And this is a bad thing.

I was wrong back when I said there ought not to be federated provisioning. The reality is that enterprises have multiple little “p” provisioning systems and processes. Help desk, email, a COTS provisioning tool – all of these can act as a fulfillment mechanism, and in the enterprises I talk to, all of them do. Different kinds of systems often require dissimilar fulfillment mechanisms. Cloud-based applications are no different. A static push-based approach to provisioning cloud applications will replay some of identity management’s troubles past. A more dynamic, more pull-based approach is the way to go.

There is a lot of work yet to be done. It’s good to see Nishant provide some interesting dynamic approaches to federated provisioning. I hope others join in this effort as well as the need effort to start building approaches to federated Provisioning identity and access governance for cloud applications.

Comments are closed