Home > iam > RBAC and ABAC and Roles, oh my.

RBAC and ABAC and Roles, oh my.

So I missed the Kuppinger Cole webinar with Felix Gaehtgens on ABAC, but I read the materials and the Q&A was really good. What it got me thinking was that there may not be enough good stuff in the world explaining the basic differences between RBAC and ABAC and why one may be better than the other. So here’s my take on it.

First, let’s set up what RBAC is. RBAC stands for Role Based Access Control. The idea is that instead of granting individuals access to assets the access is granted to a role. Individuals are then associated with the role and thereby gain access to the assets. Like with so many things, there is a decent wikipedia article on RBAC, but it fails to capture some of the basic flaws I see. If you were to draw a picture of RBAC, it may look like this:

From left to right in the above diagram, you have the asset to which access is being granted. Then there is some form of a rule which is controlling access to that asset. If the asset were a file, then the permissions in the filesystem for that file would be the rule. Then you have the roles. The roles can have users associated in a number of ways. Attributes can determine the user being associated. Rules can also be used to determine role association. And a user can also simply be declared to have a role explicitly. Last you have the users and all their attributes. If the users were in AD, then the attributes would be all the attributes of the user object. In this RBAC model, the assumption is that controlling and maintaining access is easier since there doesn’t have to be a direct relationship maintained for every user. The roles act as an abstraction layer. When assets were all files and the rules that governed access to them were very simple, that made sense. Now assets are much more than files on disk, there is almost always a middle application tier involved, and the rules are very robust.

In this newer, application ruled world, there are many issues with RBAC. First, asset owners must be aware of role details in order to make their choices about what roles get access. To grant access to the wrong roles means granting access to the wrong user. So all the logic for the granting of the role must be understood by the asset owner and that means almost no advantage in terms of spreading out load for maintenance – everybody must understand everything. Second, there are now two layers of abstraction, rules and roles. This results in some very complex interactions which make it hard to get a grasp of just how access is being granted, and that is very bad come audit time. Third, access is now dependent on role maintenance. If there is a group maintaining the roles with a complex and locked down change control procedure and a nimble application group which needs a lot of changes, you end up with process timing mismatches that can cost real money. And last but far from least, new use cases for assets means new roles. Because the rules can only result in a pass or fail for roles, if there is a need to have a different access scenario there will be a need for a new role to match it. And that means role proliferation and more maintenance.

For those reasons and more, I believe ABAC is becoming more popular. ABAC is Attribute Based Access Control. It’s picture is much more simple:

Right away, it’s clear ABAC is cleaner. It eliminates the man in the middle and puts the users right in touch with the assets. The abstraction layer RBAC provides has become overhead in the face of the new ways the assets can govern themselves. The rules assets can use via their applications are more than enough to give flexibility to the asset owners. And since the users are likely to have a good set of attributes to draw on for evaluating their claim to access, there is no reason to add the other layer of roles to mitigate. The rules can simply evaluate attributes and be quite abstracted from the actual users. And since it’s much more likely that attribute stores are well maintained since they are linked to HR and other time and legally sensitive business drivers, there is much less likely to be issues with asset owners outpacing the maintenance of their source of access control information.

Of course, roles are not simply going away. The role of roles is changing. The new picture is really more like this:

The roles are not directly involved with access control rules – except perhaps that they may show up as an attribute of the user and be used in the rules evaluations. But the roles are very useful in the administration of massive sets of users. They are also very useful in the attestation, auditing and other security and identity processes around entitlement management. Maybe it’s time to think of RBEC, Role Based Entitlement Control. The idea being that entitlements, the security view of business rules for access, are governed and audited via roles. But we can keep the OLTP side of access control, the effective controls, in an ABAC form.

That’s a lot of typing. Hope someone finds it useful…

  1. Matt Flynn
    November 5, 2009 at 3:01 pm

    Hey Jonathon, nice entry! I know it was a lot of typing, but I was wondering if you'd elaborate on why the distinction is important. Isn't ABAC (as you described it) just one way of implementing RBAC? I've seen many companies use AD groups as their way to implement Role-based access, but whether it's attributes, groups, or some complex role management solution, I see them as various ways to simplify the mgt of entitlements via grouping permissions, which seems to be the primary goal of RBAC. Am I missing the point?

  2. Mat
    November 5, 2009 at 7:59 pm


    I'll attempt to answer for Jonathan, and he can correct me.

    With ABAC, you are basically protecting assets with rules (XACML perhaps), and access is granted or denied based on the evaluation of the rule. The rule can contain required attributes for evaluation, and the rule might look as simple as this: "Is this person's title 'Burger Flipper'"

    With RBAC, the determination of granting or denying access would go more like this: The asset can be read by people in this role "Short-Order Cook"; does this person have the Short-Order Cook Role? In this case, the access control relationships are between the Role and the Asset, and the Role and the User.

    The ABAC/RBAC combination would look like this: "Does this person have the 'Short-Order Cook' enterprise role?" In this case, the rule used to evaluate the access decision is utilizing the Role assignment as an attribute.

    … hopefully this is what Jonathan had in mind… My typical day is spent dealing with the OTHER aspects of RBAC that he mentioned: "roles are very useful in the administration of massive sets of users. They are also very useful in the attestation, auditing and other security and identity processes around entitlement management"


    Mat Hamlin
    Twitter: @MatHamlin

  3. November 6, 2009 at 1:39 am

    Mat has basically nailed it. Sorry it took me so long to reply and sorrier it had to be on a whole new system.

    That small difference in implementation makes a very big difference in the overall ease of maintaining things over time. Attributes, and the directories that maintain them, tend to be in much better shape and more apt to be automated and productionized than specialty systems used for role management.

    The example you give, Matt, groups in AD, is a prime example of how things can get out of control when you try to use a container where you want a rule. How many places have massive group proliferation to accommodate all the access needs? How many times do you have 20 groups all with similar names and nearly identical members to make sure there’s just the right access to resources? Quest’s own ActiveRoles makes a lot of its sales based on the ability to transform a group from a dumb container to a smart rule based entity – which is basically making it attribute driven.

    Hopefully that makes it clearer. Good discussion! =]

  4. November 6, 2009 at 2:17 pm

    Thanks for the responses. I get the technology differences and how the two approaches function. I guess I’m trying to understand the value statement that one is better than the other. And I have no skin in the game here – no reason to argue for one or the other. I just find this an interesting topic to explore.

    Wouldn’t RBAC vendors claim that their solutions are based on rules as well? And if we agree that a rule-based approach is best, rules can be based on an account’s OU, group, attribute value, etc. — all of which can grow out of control over time. And all of which can be used to define a role. What is it about attributes that makes them easier to manage over time? (Technically, group membership is just another attribute)

    Are we simply saying that abstracting roles to another system is yet another step that increases complexity unnecessarily? And creates yet another set of data that grows unmanageable over time? And that using built-in directory attributes simplifies the infrastructure and management? If that’s the point, say no more – I get it ;)

    btw – good to meet you Mat H, I’m now a follower.

  5. November 6, 2009 at 3:56 pm

    What I’m saying is that the extra abstraction increases complexity, but with a few more points. So I will say a bit more =]

    That abstraction was at one point a good thing, but with the increase in the ability of the rules at the asset/resource layer to build in required complexity that abstraction seems to be more obfuscation than assistance. The directories are generally more easily and more painstakingly maintained. So they just tend to be a cleaner, better place to go for what is required.

    But, as Mat observed, the roles still have a place in the administrative side of entitlements (abstract access). So there is a place for all of it, it’s just a question of what the right place is. Of course, I’m open to the possibility that I’m barking mad. =]

  6. April 5, 2011 at 2:21 pm


    Thanks for this blog. It remains relevent today, which in my appreciation is a sound test of reliable bloggers. A nit of a note…… I think in the text just above your ABAC + RBAC diagram you meant to say… “Of course, roles are [NOT] simply going away.” Sorry for the niggle. :) and thanks again I will be a follower.

  7. April 6, 2011 at 10:53 am

    Lawrence I welcome every niggle, nit, jot, and tittle of constructive criticism and especially correction. Glad to know people are getting some value out of my posts. It feels indulgent to write them…

  8. Patrick Parker
    May 26, 2011 at 9:15 pm

    I just read an article on this topic takes a different slant on the issue – an interesting read with many valid points: http://www.katasoft.com/blog/2011/05/09/new-rbac-resource-based-access-control

    The challenge with ABAC is a lack of auditability of who has access to what. It is very difficult or impossible to look at a user and ask “which assets can this user access”. Also, the converse is true that you can’t look at an asset and easily see the resultant people that could access it. Rules can be extremely easy to setup and flexible which is their allure but they can lead to security chaos where no one really knows what is accessible and by whom.

    • May 27, 2011 at 1:24 am

      @Patrick, there is good stuff in there. Thanks for sharing it.

      I’d have to disagree that ABAC creates any less “auditability” than anything else if it’s done right. I think one of the tacit assumptions of ABAC is that the authorization will in some form be external to the applications. That may be directly via using XACML. That may be indirectly by having something that using ABAC logic to establish something like AD group membership, which is in turn used to authorize access in the applications. But the net result of either approach is that the ABAC policies reside in one place with the information that also is used to resolve them (or the well defined means to get at that information), and that can easily reveal who has access to what. Of course, you could do it badly and end up with more of a mess than roles based systems, too.

      This resource based approach discussed in the article seems to be more about how one implements controls at the application layer to make them more self documenting. And what they suggest for that is very sensible. But the “if (user.isPermitted(“projectReport:view:12345″))” pseudo-code snippet doesn’t define what the function of “isPermitted”. Does that make a call to some external decision point? Does that use function defined elsewhere in the application itself? I think it is supposed to imply an external engine since they talk about external stuff later on. And then that begs the question: how does that external decider make the call? The resource that’s the object of the call is key to that, obviously, but it will likely use attributes, rules, roles, or all of the above, too. So it seems to me to fit into the spectrum not overturn it.

  9. Patrick Parker
    May 27, 2011 at 1:44 pm

    I agree with you completely that the authorization needs to be external to the application. The challenge as I see it is when you have abstract rules and attributes with no linkage or reference to the resources (aka assets) they protect. In a simple example using groups, attributes and applications. The applications are protected by consuming rules that leverage group memberships in combination with user attributes. An example might be that ApplicationA uses an access rule where All Users that are members of GroupC and where user.title contains “sales” and user.division is not “Widgets”.

    This is a great example of the extremely flexibility of an ABAC-based approach as the application can simply point to a rule and the rule can contain almost any syntax desired (may not perform acceptably in real-time but that opens up another whole set of issues). The challenge lies in how disconnected the application being protected is from the rule and the disconnect between the conditions contained in the rule specifying the group and the attribute checks.

    The following common audit questions arise from this scenario that would be extremely difficult to answer if at all:
    1. If I’m the application owner, how can I see which users have access to my application and how they got this access? Do I need to learn to read these new rules? Would I have access to read them? How would I determine who matches the rule – who are these users? How would I grant a few users access to my application now?
    2. If I’m the owner of GroupC how do I know the consequences of adding someone to my group? I’m assuming that GroupC is a general purpose group and was not created specifically for ApplicationA because that would make it a pseudo-application role and go against the goal of ABAC to use what information already exists for authorization.
    3. If I’m an auditor, how do I audit how access is granted to application and who is granting the access? Was it the person that added the user to GroupC that granted the access to ApplicationA or was it the HR staff member that changed the user’s Division to Widgets? Who is accountable?
    4. What is the security weight now associated with the title and division fields on a user and from how many sources could this information be edited and by whom. Now we need to wonder how many different people editing data in how many different directories are now wearing the “Entitlement Manager” hat in our organization.
    5. How does an auditor monitor the transitions as users are dynamically granted and revoked access to sensitive applications in this scenario? There wouldn’t be a log of who had access on Monday versus Friday because access is only evaluated at runtime when demanded.

  10. May 27, 2011 at 3:04 pm

    I think maybe we’re talking past one another. All the problems you’re pointing out are very real. And they exist in every customer I talk to. They are symptoms of how access control has been handled in the past (for the most part). Most places don’t have RBAC (roles), ABAC, or anything that formal at all. If they are lucky they have groups doing access because that’s at least better than everything being completely isolated – meaning that they have a chance to figure out what’s what because they have a basis to start investigating. And, of course, many vendors (including Quest I’m obligated to say) have solutions that would help people start connecting those dots.

    All I’m attempting to do in the original post is lay out what RBAC and ABAC are, what’s different about them, and how I’ve observed them being applied. It’s not an attempt to lay out a best practice. If it were, it would likely be 100,000 characters longer (give or take 10,000 or so). But I’m sure that it would then contain a whole discussion of the role of resource cataloging and having transparency of resources in the rulebase to address exactly the issues you are raising. I’ve seen a few very mature customer environments were they are using CMDB approaches to achieve just that kind of visibility today. And, again with deference to my sponsor, I’ll point out that Quest’s Identity Manager allows you to do just that as well. But the truth is that most people I talk to are so buried in day to day struggles with infrastructure, operations and compliance fires around IAM that they rarely stop to think about how they can restructure their application access control approach to be more in line with best practice. And when they do, they often have to start by trying to recall what all this crazy NIST and OASIS stuff means and how it is related to their world. So I thought I’d write out my way of seeing a small part of it as it stands today as a helper to that audience.

    The only way to answer the questions you’re asking in most organizations today ir to go through painful and intrusive reporting, discovery, or certification exercises. And none of those actually solves the underlying issues. They just let them pass the audit, or answer the executive, or meet some other transitory goal. So don’t think I’m saying you sprinkle a little ABAC fairy dust on these issues and they go away. I mean nothing of the kind. =]

  11. Serge
    July 5, 2016 at 9:32 am

    Hi Jonathan,

    After all these years your blog post is still very relevant for the subject and the comments only add value to the discussion. Thanks for that!

    I have a question, please: can I use the graphics you have posted here provided that the source will be mentioned?

    Thanks again.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: