Don’t want to read all of this? Check out the video:
Why do human continually seem to reinvent what they already have? Why is it that we take a reasonably functional thing and attempt to rebuild it and in doing so render that reasonably functional thing non-functional for a while? This is a pattern that is familiar. You have a working thing. You attempt to “fix” it and in doing so break it. You then properly fix it and get a slightly more functional thing in the end.
Why is it that we reinvent the wheel? Because eventually, we get a round one. Anyone who has worked on technical standards, especially identity standards, recognizes this pattern. We build reasonably workable standards only to rebuild and recast them a few years later.
We do this not because we develop some horrid allergy to angle brackets – an allergy that can only be calmed by mustache braces. This is not why we reinvent the wheel, why we revisit and rebuild our standards. Furthermore, revisiting and rebuilding standards isn’t simply a “make-work” affair for identity geeks. Nor is it an excuse to rack up frequent flyer miles.
Identity in transition
We reinvent the wheel the tasks needed of those wheels change. In IAM, the shift from SOA, SOAP, and XML to little s services, REST, and JSON was profound. And we had to stay contemporary with the way the web and developers worked. In this case, the technical load that our IAM wheels had to carry changed.
But there is a more profound change to the tasks we must perform and the loads we must transport and it too will require us to examine our standards and see if they are up to the task.
It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? And not just right people but also right “things” – did they get the experience (or data) they needed at the right time.
There is another transition underway. This transition is closely related to IAM’s transition from delivering and managing access to delivering and managing experience. We are being asked to haul more and different identities
We are pretty good as an industry at managing a reasonable number of identities each with a reasonable number of attributes. Surely, what is “reasonable” has increased over the years and it is fairly safe to say that no longer is a few million identities in a directly a big deal.
But how well will we handle things? Things will have a relatively few number of attributes. Things will produce a data stream that really interesting but their own attributes might not be that interesting. And, needless to say, there will be a completely unreasonable number of them: 20 billion? 50 billion? a whole lot of billions of them.
The transition of IAM isn’t just from managing identities of people carbon-based life forms to silicon ones. This transition also includes relationships. Today we are okay at managing a few relationships each with very few attributes. But what we as an industry must do is manage a completely unreasonable number of relationships between an unreasonable number of things and each of these relationships has a fair number of attributes of their own.
That, my friends, is a heavy load to haul. And so it is worth spending a little time considering if our identity standards wheels are round. Let’s look at 4 different areas of IAM to see if we have round wheels:
- User provisioning
Overall, I’d say the authentication wheel is round. We’ve got multiple protocols, multiple standards, which is both a reflection of the complexity of the problem and the maturity of the problem. OpenID Connect needs a few more miles on the road, but by no means does this mean you shouldn’t use it today. Expect new profiles over time but you certainly can get going today. And where OpenID Connect cannot take you, trusty SAML still can.
Although authentication is okay, representing assurance isn’t. I wonder if we need to harmonize level of assurance. I also wonder if this is even possible. Knowing that a person was proofed and how they were authenticated is nice, but as Mark Diodati will be the first to tell you deployment matters. You can deploy a strong auth technology poorly and thus transform it into a weak auth system. So knowing your LOA 3 is equivalent to my LOA 2.25 might not be useful. More importantly, I wonder how small and medium sized organizations, those without a resident identity dork, figure out what LOA to require, what trust framework to use, and how to proceed. This, to me, seems like a place for the IDESG and its ilk.
And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down. Second, the fact that password vaulting exists at this point in history is an embarrassment. To be clear, I am not saying that password vaulting solutions and vendors are an embarrassment. It is the fact that we still have the need to password vault is IAM collective shame.
We have had workable authentication standards for this many years and yet we still password vault. It means that identity vendors have not done enough to enable service providers. It means that service providers still exist who do not want to operate in the best interest of their enterprise customers. At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.)
Let me be crystal clear: if your service provider doesn’t support identity standards, that service provider is not acting in your best interest. Period.
The existence of password vaulting also means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands.
I know we are all trying to kill the password but I think a more reasonable, more achievable, and more effective goal is to eliminate the need for password vaulting through the use of authentication and federated SSO standards. By 2017, if I am still saying this, our industry has failed.
Authorization’s wheel is simultaneously over-inflated and flat. You can’t talk about authZ without talking about XACML. XACML can do anything; it really is an amazing standard. But the problem with things that allow you to do anything is that they tend to make it hard to do anything. My recommendation to the industry is to focus on the policy tools and the PAPS, not the core protocol. Now the XACML TC knows it needs to be contemporary. The work on the JSON and REST bindings is a great start to make XACML more relevant for the modern web.
What about OAuth? Certainly OAuth can be used to represent the output of authorization decisions. But to do this, in some sense, requires diving into the semantics of scopes. It requires that your partners understand what your scopes mean. Understanding of the semantics of scopes isn’t a horrible requirement, but it does require service providers have to invest time to understand that.
What about UMA? It definitely holds promise, especially when we consider the duties of all the parties involved in managing and enforcement access to resources. I really like the idea of a standard that has a profile that describes duties of the actors separate from the wireline protocol description. UMA definitely needs more miles on the road and to be perfectly honest I still have a hard time understanding it in an enterprise context. Maybe now that Eve is coming back to the product world, the community will get more UMA awesomeness.
There is another thing to think about as we study the roundness of the authorization wheel. Knowing that the load we will have to carry is a heavy one and one that includes “things” I think we need to think about how those “things” can make decisions with more autonomy. How can our authorization systems make authorization decision closer to the place of use at the time of use? I believe we need actionable relationships. Actionable relationships allow a thing or a human agent to be able to do something on my behalf without consulting a backend service. Very important in the IoT world. For more on actionable relationships, you can check out my talk on the Laws of Relationships.
Tomorrow I’ll post the rest of the talk and hopefully by Friday the video of it will be available as well.