My GlueCon Talk on “Federated Provisioning and the Cloud”
Last week I attended GlueCon, a 2-day developer-oriented conference focusing on the technologies that make/will make the cloud go. As usual, Eric Norlin and team did an excellent job curating a conference with lots of interesting content, some of which was quite new to me. And the energy levels were extremely high (I can’t remember the last time I attended a conference where you could gather this kind of schwag).
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.
Side Note: I will be speaking at the Burton Catalyst North America conference on the topic of “Beyond SPML: Access Provisioning in a Services World”. That session will explore the next logical step in this discussion – how those policy and workflow based controls can continue to be leveraged, and even enhanced, as you move towards an externalized identity architecture. |
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]
As usual, great work describing and explaining the concepts and existing limitations around Federated Provisioning.
I'm interested to hear your follow on thoughts around how to solve the “missing pieces” problems. For the missing attributes, I like your #3 suggestion in the slides (OAuth + ArisID) since it does roundtrip all parties and allows for compliant attribute retrieval. The questions that should be answered are:
What attributes are required to provision an account (or role or entitlement) on the cloud based application? (CARML)
Where are those attributes sourced from? (identity sources and/or actual people)
How is the sourcing and use of attribute data authorized? (IAS, OAuth?)
In the enterprise provisioning realm, to answer these questions you could create a “provisioning policy”, which defines per application how the attributes values are sourced? Do they come from the requestor, the application administrator, or are they mapped / calculated from known identity information? This becomes difficult in a cross domain scenario and will require the use of standards, as you suggest.
I'm also interested in your thoughts on deprovisioning, metering, and closing the audit and control loop with the enterprise-side Identity GRC system.
Cheers,
Mat Hamlin
+1 on deprovisioning. I'm wondering how the enterprise IdP can terminate or disable accounts in the RPs while the target users are offline.
+1 on deprovisioning. I'm wondering how the enterprise IdP can terminate or disable accounts in the RPs while the target users are offline.