I put my 18 minute ramble/rant on Killing IAM out on the blog a few weeks back, and I have to say, I have been blown away by the response. Besides all the comments on the blog itself, I’ve had multiple people take me aside to discuss some of the implications of killing IAM off so that it can be reborn. And I have to give Michel Prompt at Radiant Logic a special call-out for not one, but two, blog posts in response to what I said.
Before I respond to Michel, it is interesting to note what people did not take issue with. Stateless identity, apparently, isn’t too controversial. I think we can agree that identity needs to be where the developers are and increasingly, especially in the mobile setting, this means in a RESTful world – one in which stateless identity is well suited. Furthermore, people didn’t take too much issue with my assertion that OAuth, SCIM, and OpenID Connect, although by no means perfect, are going to be a major part of the future of IAM.
Another thing people didn’t disagree with was my assertion that identity has to be interwoven into services the business craves. Baking identity into the platform is simply just how all major services providers will proceed. To be fair, there was plenty of comment and disagreement over what the impact will be to smaller identity technology providers. But I think we all agree that the way identity is procured and consumed is still evolving.
So, coming back to Michel’s well written rebuttals, the thing I mentioned that seemed to strike a nerve and cause discord was the point that in order to model and manage relationship hierarchies graphs are needed. Caught up in the response was the implication that graphs (and network databases) are superior to LDAP and SQL.
Let me be crystal clear – I didn’t come to throw stones at SQL or rehash the “should I use a directory or a database” conversation. (I agree with most of Michel’s post regarding the storage of information.) My concerns are over the representation of relationships and identities, not the storage mechanism for those relationships and identities. Given the world of complex relationships we live in, the tools we have today for managing “who can get access to what” are poor. The tools are low fidelity. They rely too heavily on artificial hierarchies.
We need richer semantic representations of relationships and identities accompanied by policy management tools that use that richness. Writing authorization policies requires high fidelity; it requires a means for business analysts to express in their own business terms the rules of the road. I believe that a graph representation of relationships and identities can empower such tools. How that data is stored – I leave to data management professionals.
In closing… To Michel – you’ve got identity virtualization capabilities. How hard is it to build an OpenGraph API on your technology? To Microsoft (and Kim specifically) – we’ve been hearing about the power of graphs and Azure AD has such an API. What are people doing with it? To Oracle, IBM, Axiomatics, Dell, Next Labs, ObjectSecurity, and anyone else I left out – show the industry what your authorization policy management tools can do. Let’s see real relationship modeling and management. Let’s see high fidelity policy tools. Catalyst. July 29th to August 1. Come show the world what you can do.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.