So is Windows Azure AD a Provisioning Engine?

While the identity community is consumed by the “SAML is a Zombie” and “OAuth is Evil” debates, I wanted to go back to a slightly older topic of discussion. Almost 2 months ago (my, how time flies when protocols are being given the business), I wrote about Windows Azure AD and the necessity to understand in more detail how Azure AD’s current and future capabilities fit into the IDMaaS vision that Kim Cameron has been talking about. Part of the discussion on Twitter has pertained to the notion of user provisioning, and how Microsoft’s development of Directory Graph API in Azure AD complements or competes with the developing SCIM standard for account management in SaaS applications. In particular, I asked in a tweet the question

Re. @Kim_Cameron (http://bit.ly/NroKfa ) & @MartinKuppinger (http://bit.ly/O3Iwex ) posts, posit that Graph API:IdPs :: SCIM:Apps. Too simple?

I was essentially contending that Directory Graph API would primarily service the Identity Provider scenarios where a SaaS application could rely on an externalized identity store for identity claims, while SCIM would be the API that SaaS applications would support so they could be “managed” by a provisioning infrastructure. My question would prove prescient.

Before I left for the Cloud Identity Summit, I had tweeted that one of my goals at CIS would be to dive into this topic. And John Shewchuk was kind enough to seek me out (thanks John Fontana) and grant me some insight into the vision for how they expect Azure AD (he does not like the acronym WAAD!) to address that aspect of identity management in the cloud. It was a very good discussion, and I hope I do it justice here (but I’ll rely on John, Kim and others to keep me honest).

User Provisioning in the Cloud

Two years ago, at Catalyst 2010, I gave a talk entitled Beyond SPML: Access Provisioning in a Services World (wow, we do like to declare standards dead a lot, don’t we?). You can check out the slides from my talk here, if only to enjoy the manner in which I eviscerated the Black Knight of Identity, Ian Glazer, while simultaneously earning myself the title of Iron Man of Identity. More relevant to this discussion though was my exploration of how provisioning, in particular Just-In-Time Provisioning, would need to evolve in order to service the growth of SaaS apps in a highly decoupled environment. JIT Provisioning was the cornerstone for my view of the next generation of provisioning, living as it would on the backbone of federation interactions like SAML or OpenID flows. It involved SaaS applications using the basic claims received as part of the initial identity interaction to connect with the “Provisioning based IdP” (as I called it on slide 28) and retrieve the attributes and claims needed to create the identity in their own identity store. Further, in order for the SaaS application to then know about changes to the identity and stay in sync with it, a notification mechanism would be needed (see slide 31). This voids the need for a synchronization mechanism (directory synchronization or user provisioning) as the only way to keep SaaS applications updated, and instead makes it more of a pub-sub model that empowers the SaaS application to get notified about changes, and pull them in if and when they need to do so.

And this is essentially how Directory Graph API and Azure AD tackle the prospect of user provisioning. Directory Graph API is inspired by another identity platform API: the hugely successful Facebook Graph API. That API includes a mechanism for change notifications called Real-time Updates. Any application using Facebook can subscribe to changes in data in Facebook, allowing the application to “cache” data and receive updates. Whenever a subscribed change occurs (say to a user, or a users list of friends), Facebook makes an HTTP POST request to a callback URL the application specifies with a list of changes. This is the mechanism that Azure AD plans to adopt (this capability is not available yet, and was the missing link for me) that allows it to actually enable the JIT Provisioning model I described above. In effect, the Directory Graph API with Notifications allows Azure AD to become the Provisioning based IdP I refer to on slide 28. That’s pretty cool.

Rubber, Ready to Meet Road?

And that is how Directory Graph API becomes both competitive and complementary to SCIM. They address two completely different provisioning models – SCIM is clearly aimed at the more traditional push-based provisioning architecture that we are familiar with (you can see where it fits into the model described in slide 4), while Directory Graph API is positioning itself for the newer pull-based provisioning architecture.

And therein lies the real challenge. Because as I pointed out in my previous post on Azure AD, getting application architectures to change is really, really hard. SCIM can be layered on top of existing application architectures easily, providing a quick solution despite the shortcomings of the model. Directory Graph API requires applications to change how they consume identity, which is a much harder proposition – especially in today’s world where polyglot architectures and liberal use of 3rd party tools and open source impose constraints on what you can do. Facebook succeeded in getting many applications to adopt this model, but those were being built from scratch and (usually) had simpler use cases and concerns.

And from an enterprise perspective, the control mechanisms are still unclear in the new model. It’s very easy to understand how one centralizes policies and controls into the provisioning engine in the push model to control what data is being sent when, to which applications and for which identities. In the pull model, figuring out when to allow or deny the pull of identity data and subscription to changes requires a rethinking of both the authorization model as well as the control framework (approval workflows, de-provisioning, etc) governing the identity data flows. And like I’ve said all along, governance models like access certification and “who has what” reporting can prove to be a lot more complicated in a highly decoupled architecture like pull-based provisioning. And while I wouldn’t dream of pushing more enterprise use cases onto a simple protocol, these are core problems to be solved. If Facebook were to be more diligent about privacy or concerned with data protection, this might become an issue for them as well.

To bring this back to where we started, the missing pieces show that Azure AD is clearly about more than “Directory in the Cloud” or “AD in the Cloud”. And it isn’t a provisioning engine either, at least in terms of how we traditionally think of them. It is trying to position itself at the heart of an IDaaS platform, where externalized identity is supported through a pull-based infrastructure. This is a path others are following as well, but what Microsoft (crucially) has is the ability to influence how application architectures evolve to make this a practical reality. That is the key.

Oh, and answering those pesky governance control questions.