The Debate over RBAC vs. Entitlement Management

The folks over at Securent are onto a good thing with the community driven blog they started called simply the Entitlement Management blog. They have managed to get posts from an impressive set of contributors, including Burton’s Gerry Gebel and Forrester’s Andras Cser. Check it out when you get a chance.

What caught my eye was this post a while back by Securent CEO Rajiv Gupta, that touches on the type of debate one often sees at the inception of rival approaches to a problem. While the RBAC vs. EM debate does not compare to the aggravating Blu-Ray vs. HD-DVD format war, there are similarities in that both are forcing some consumers into a “wait and see” attitude, and emotions fly high whenever this topic is brought up.

Despite repeated requests in the blogosphere I have resisted the urge to discuss EM’s place in IAM, primarily because I did not feel knowledgeable enough about the space to comment on it (people who know me know that I am cautious to jump into any debate, but once I have an opinion I am in it as much as possible). One gating factor in my involvement and a possible factor in the ongoing debate – the lack of industry agreement on what exactly we mean by the term “Entitlement“.

Vagueness in the definition of a term can be to the advantage of the players in the associated space, as it gives them flexibility to sell into more customer scenarios (something we at Thor saw happening plenty in the provisioning space back in the day). But it also engenders the kind of debate now raging, where there are folks who believe that RBAC and EM are rival methodologies to solving the access control problem (remember when access control simply meant SSO?).

Roles and Entitlements are both abstractions that have been created to make access rights management of identities easier. It would seem to me that the difference between the two is one of perspective. Entitlements often encapsulate into a meaningful singleton the set of privileges (usually across different tiers – UI, business logic, data layer) needed to perform a specific action. So the perspective is that of the application. Of course, that does not prevent anyone from breaking an entitlement down into more atomic pieces, or aggregating entitlements up into higher level entitlements (that may span applications). Roles start from the (very human) need to somehow put a descriptive moniker on an identity’s abilities in context (of the enterprise or the application). They therefore tend to be from the perspective of the identity, and in some sense fulfill a social imperative to quantify a person’s context.

If we buy into this argument (and I am not suggesting we do that just yet), roles and entitlements intersect in the middle. One of the problems that existed in the early days of role management (not that we are in late days right now) is the role explosion problem. This existed primarily because of two reasons – (i) the simplified definition of a role as simply another multi-valued attribute and (ii) the need to map roles to low-level privileges. That is why folks implementing roles would end up with the kind of roles Rajiv refers to in his post – “Sales Manager EMEA“, “Sales Manager Asia Pac” and “Sales Manager EMEA before 5pm“. It also was the reason why roles failed as a business description of the context of an identity, since the constituents of the role were unintelligible. As roles have gotten more sophisticated (supporting attribute-based dynamic membership, relationship-based contextual membership, even session data based membership), they have become more usable as tools in the expression of policy.

And entitlements add an extra layer of indirection, making it possible to reduce the complexity of the role definition itself, while providing manageability around the definition and control of access rights from the application developers and application owners’ perspective.

To try and conflate the two is to miss the point. True scalability in IAM is achieved only by putting a delegated model for administration in place. Roles and entitlements allow you to put the right controls into the hands of the right parties. In a simple world, application owners can define application entitlements, business owners can define roles, and governance folks can define the mapping between the two. Of course, the world is seldom simple, and the administration lines start to blur, leading to notions of application roles (the early precursor to entitlements) and enterprise entitlements. And that is where one wonders how all this comes together.

The primary reason behind the debate is encapsulated in a question asked (quite often now) by our customers and prospects – “Where is the ONE place I can go to and see my access policies from end to end?“. And therein you will find the heart of the problem. As long as there are different components in the solution, it is hard to provide a complete end-to-end view. And that is why I do not expect this debate to die down any time soon.

Of course, my views here could be completely off target. I would love to hear your thoughts on this.