Over the course of the last few days, there have been many posts being published in different blogs, including the ones of Craig Burton, Nishant Kaushik of Identropy, KuppingerCole’s Dave Kearns and for sure Kim Cameron and John Shewchuk.
I won’t dive into the discussion taking place between Craig, Nishant, Kim and others but clearly have to say that I’m fully with Craig on that it is about “Freedom of choice” and that this is fundamentally different from the “Freedom to choose your captor”.
My main points later down will focus on the blog of John. However, when looking at the initial post of Kim, there is also one important aspect I want to stress. Besides the fact that we will use more identity services and that they have to provide a lot of features, there is another important trend which I observe. We will in the future rely on more than one identity service. The fundamental change is that the relation of authentication and authorization will change from a 1:n relationship to a m:n relationship. What does this mean in reality?
Today we tend to have relatively static access management, where a user authenticates, obtains a ticket or something like that and then this ticket from one identity provider is used for several authorizations within a session. This will change. When you look at the idea of claims, they potentially can be issued by different identity providers. They are used in dynamic authorization decisions. You might even have different claims from different providers per decision. Trust might differ depending on the importance of the claim and its provider. It’s sort of a convergence of authentication and authorization. And in that world where you receive attributes (or claims) for authorization decisions from many providers, the role of identity providers will change. Microsoft’s WAAD approach its the planned interfaces definitely helps in moving towards such a concept.
But let’s now look at John’s post and some things I’ve learned since then. He focuses pretty much on WAAD as something that is mainly made for Office 365 and Azure, so it is the classical Microsoft-focused environment. However that raises the question: “Only for these environments?”
That, from my perspective, is one of the big questions: How can you make that work for everything in a controlled, secure way? I assume this will be covered more in depth in the next part of John’s blog. And from what I know today, besides a set of RESTful APIs there will be other interfaces, including OpenID connect, SAML and so on. However there won’t be an LDAP interface at the beginning, even while you could potentially build that by wrapping the RESTful APIs. Not supporting LDAP directly at the beginning definitely is somewhat surprising, but it stands also for a change towards what we call the Open API Economy (have a look at Craig’s blog and the KuppingerCole report on that topic).
Another interesting question which came to my mind was: What about structuring Active Directory? The biggest problem with Active Directory from my perspective never has been running the directory itself but dealing with two issues
- Structures like domains and forests (and even more: restructuring)
- Security, as well inside AD as by defining different types of groups in an appropriate, manageable way