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 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...
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?
ReplyDeleteMatt,
ReplyDeleteI'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"
Cheers,
Mat Hamlin
Twitter: @MatHamlin