How Do Governance Controls Fit Into IDMaaS?

Kim Cameron has a vision for where identity management is going, and he has started to lay it out in a series of blog posts, starting with this post on ‘Identity Management as a Service‘ (where he unfortunately reopened the IDaaS vs IDMaaS acronym debate). I think most of us would agree with his statement that “Identity Management and the way it is delivered will change dramatically over the next decade” in response to many factors like cloud computing, mobile computing, consumerization of IT and the new ways in which people will collaborate and work. I (among others) have been saying for years that this will push the technology of identity management towards a services model (see my talk about Identity Services from Digital ID World 2007). Craig Burton thinks that this vision, and the associated work Microsoft is doing on Windows Azure Active Directory (as described in this post by John Shewchuck) is “profoundly innovative”. I’ll be honest, I’m having a little trouble seeing what is so innovative about WAAD itself. How is the fact that becoming an Office 365 customer automatically gives you an AD in the cloud that you can build/attach other Azure applications to that different from Oracle saying that deploying a Fusion Application will include an OUD based identity store that the enterprise can also use for other applications? It might possible that this could work if you are apart of the office 365 distribution group. Apart from being in the cloud and therefore far easier to use in federated identity (SAML, OpenID, OAuth) scenarios. But I’ll wait to hear more before commenting any further (though John Fontana and others have already weighed in).

What I was surprised to find missing from Kim’s and Craig’s discussion about IDMaaS were the governance controls one needs in identity management (and therefore IDMaaS) – like approval workflows, access request and access recertification. In other words, those crucial business tools in identity management that have led many analysts and vendors (including me) to repeat on stage many, many times that “Identity Management is about process, not technology”. And this is the part that makes identity management, and therefore IDMaaS, really hard, as I alluded to in my talk about ‘Access Provisioning in a Services World‘ at Catalyst a couple of years ago.

In an IDMaaS model where identities are externalized and people bring their own identities to work at their employee and partners, how do we give the organization governance controls to manage correct access? How does a doctor request access for a contractor that is working with her? How does this access get approved by the appropriate administrator within the hospital? And 6 months later, how does that hospital administrator review all the access this contractor has across all hospital systems to ensure that it is still appropriate?

In his follow-up post, ‘Identity management before the cloud (part one)‘, Kim says “In the domain paradigm identity management was thought to be the CRUD and little more.”. But that is not true. What made identity management so hard and expensive was the need to supplement the CRUD features with a governance layer that included policy and process to manage over the entirety of the identity management infrastructure. The responsibility for this was early on thrust upon the provisioning products like Thor Xellerate and Waveset, and later on spawned more specialized handling in IAG products like Sailpoint and Aveksa. Kim alludes to these when he says “A category of Identity Management integration products arose … often brittle point products and tools that could only be deployed at high cost by skilled specialists”. That’s accurate, but not because they were pointless or overhead or overkill. These products were difficult to deploy and needed customization because it wasn’t well understood how to introduce the controls needed in IAM in a manner that was practical and usable. And it was always assumed that every customer would demand unique business processes, so the approach was a toolkit approach rather than a solution approach.

And an IDMaaS architecture as alluded to by Kim and illustrated by Craig in this diagram just makes the solving of this problem more difficult and even more critical due to the zero trust environment. Since the identities have not been created and are not controlled by the organization that needs to make the access decisions, approval and review controls become even more important because they’re all the enterprise has. The ability to de-provision access based on events or manual intervention becomes a crucial component of access lifecycle management. These are the safety measures the organization needs to put in place for security and compliance.

And where do the new claims/assertions (today they would likely be roles or application privileges) about the identity that the access processes introduce get stored? Not in WAAD, I think, because past attempts to map all access grants and entitlements in the enterprise’s entitlement catalog to AD groups have not worked out. I’ve always felt that one of the biggest challenges facing Enterprise IDaaS was the need to compose, in real-time and at scale, a context sensitive identity that combines assertions from various authoritative sources (selected based on the usage context) with a core identity from the users chosen identity provider. Not exactly an Identity Oracle, but similar. Now that’s an IDMaaS construct that would be truly innovative and game changing.

[Cross posted to the Identropy Blog]