RBAC and ABAC

Role-Based Access Control (RBAC) has been around for decades. It is both loved and hated. Over the years many newer access control models tried to improve on RBAC. Many of these developments focus on making the model more flexible. Attribute-Based Access Control (ABAC) is perhaps the most prominent model in this category. Quite recently there was a new contender in this space: Function-Based Access Control (FBAC). I’m quite well known for my reservations regarding ABAC. However, reading about the FBAC I have realized that I have never put my thoughs into some consistent form. The FBAC model inspired me to this – as FBAC is obviously an improvement, however, it still has some major drawbacks that seem to be common to many access control models. I would like to briefly describe these drawbacks in this post.

ABAC and FBAC and similar flexible access control models seem to make a lot of sense when you look at them just from the authorization perspective. These access control models are great for making authorization decisions. That means when all you care about is deciding whether to allow access or deny access. And this may be perfectly sufficient for simple scenarios. But the world is not a simple place. And authorization is not the only use for the access control model. There are few more areas that need to be considered: management, accountability and analytics.

RBAC and RBAC-based data models are relatively easy to manage. No, what I mean is not the idealistic principle of grouping privileges to roles and “just” assigning the roles afterwards. That may seem nice in theory, but has severe limitations in practice. It does improve manageability, but the improvement is much smaller that one would expect. What is really important about RBAC and manageability is the concept of role – and the fact that a role is almost a tangible object. Let me explain.

For example let’s think about a mid-size bank and its access control policies. I have worked for many organizations like these during my career. And I have never ever seen a single one that was able to express its complete access control policy in such a way that could be translated into an algorithm. Most organizations can express 30-60% of their policies in a very precise way that can be easily turned into an algorithm. In the banking case there are typically employees in branch offices. There is usually a bank teller, supervisor and branch office manager. And that’s it. They have the same responsibilities and privileges whether you look east, west, north or south. But then there is the rest. In the banking case these are usually employees working at the HQ. It often looks like an organized chaos to an untrained eye. There are mixed work positions. There are employees working for several departments, teams and projects at once. Even employees that work in the same department and have the same work description yet do not have the same privileges. I have never seen a situation when this could be completely expressed using some algorithmic policy. And that’s where ABAC and similar models utterly fail as they depend on the algorithm to make access control decisions. But RBAC works there reasonably well. How is that possible?

This environment may look chaotic. But it is not. It is true that no single person can tell which employee should have which privilege. But this knowledge is there. It is just not centralized. It is rather distributed through the entire organization. Manager of the accounting department knows what his team members need to have their work done. Application owners can spot if someone has wrong privileges. Security officers know about dangerous privilege combinations that should not be allowed. And so on. While no single person has the complete knowledge about security policy the knowledge is still there. Distributed. If the policy has to be enforced by an identity and access management system it needs to be put together. But it is not possible to do that manually. Many employees do not even know that they have important knowledge about the security policy. They do not think about it as a security policy. If your identity management program relies on gathering all this knowledge manually and then translating it to something like ABAC rules then stop. Stop the project right now. It is very likely to be just a waste of time. Completely different approach is needed here.

The reason that RBAC works in this apparently chaotic environment is the concept of role. This is a common concept that all the responsible persons can understand. This is something that forms the common vocabulary. If an employee does not have access somewhere he will request a role that gives the access. His manager can suggest the roles that are most likely related to his job. Or the employee can look at the roles of his colleague to figure out which roles are needed. The application owner can review the roles and prohibit the use of high-privilege roles unless it is properly justified. The security officers can sort and mark the roles to implement segregation of duties (SoD) policies. The security office may easily make sure that the roles marked as “executive” cannot be combined with any of the roles marked as “controlling”. And so on. Each actor will add his small knowledge about the policy into the process. Piece by piece the entire policy is implemented.

Role is a crucial concept in a common vocabulary that can be used to make an identity management decision. And these decisions are not always algorithmic. Long ago when I was a young engineer deploying my first real IDM project I have asked the security staff how they decide if someone should have specific role or not. In that specific deployment the role was requested by a manager for the employee. That was the first step to justify the request. Then an approval of the security office was needed. And what I have learned is that the security office approves the request if “it looks good”. That was the answer that surprised me. But there is a much more behind this simple answer that meets the eye. The “looks good” means that the security will approve if the request does not go outside their usual business practice or organizational structure. They are trained to recognize that. In case that there is a suspicion they are going to make few calls and demand explanations. It seldom takes more than just a few minutes and most requests are decided in a matter of seconds. This is an easy decision to make for a trained security professional that knows his organization. But it is almost impossible for a machine to make the same decision. That is the reason why ABAC fails. And that is also the reason why RBAC works. It allows to make those decisions efficiently and responsibly by introducing common vocabulary: roles.

Now, ABAC is theoretically a superset of RBAC. Of course, roles can be expressed as attribute values. Or better to say: attribute values may act as roles. That’s the theory. But the practice is quite different. It is easy to request an RBAC role. Such role is almost tangible object. User can browse role catalog. User can look at roles that his colleague has. It is easy to suggest frequently used roles to the user. But what about attribute values? They are usually simple strings or numbers. How should an employee know what values he needs? There is usually no catalog for the values. Even by looking at my colleague’s attribute I would not immediately see what I’m supposed to ask for. There are just too many attributes and too many values that can be consequential. Even having some enumerations for attribute values is not going to help much. Roles often have description that explain what the purpose of the role is and that makes the selection easier. Attribute value enumerations won’t have that. Oh yes, it could be somehow added. But that in fact means that you are reinventing RBAC in ABAC. Which is almost certain to be a very slow and painful process.

And then there is accountability, analytics and governance. It is easy to remember meta-data about role assignment: who has requested it, who has approved the request, whether the assignment is permanent or temporary and so on. It is quite difficult to maintain the same kind of meta-data for assignment of attribute values. It is possible, but it will tremendously complicate the ABAC data model. Here we are back to reinventing RBAC once again. And there are more crucial features that are easy to do with RBAC but extremely difficult with ABAC. Try to get a list of users that have access to certain operation. It is very easy to list members of a role that gives access to that operation. But it is a different story with ABAC. First of all you need to evaluate the ABAC expressions for every single user. Not very efficient, is it? But even then you might not get a complete list. If the expressions are context-sensitive then you may not get users that have access only during certain times or from certain places. Yes, that also can be addressed in the ABAC expressions. But it is a very complex and costly way to do something that RBAC does quite easily. And there are more things. RBAC roles are usually hierarchical. They can be composed from smaller concrete pieces to larger abstract concepts. It is also easy to split the role management responsibilities to several departments. It is easy to let application owner approve every new role for his system. It is easy to estimate the effect of role definition change, manage it, approve it and roll it back if needed. It is easy to set up role exclusion (SoD). Yes, even this is definitely somehow possible to implement in ABAC. It is just far too difficult to be practical. And why bother at all as any self-respecting IDM system already has all these capabilities?

To summarize: ABAC is great for authorization. But it is terrible for management, accountability, analytics, identity governance and other high-level methods of information security.

I’m not trying to pretend that RBAC is perfect. I’m here long enough to know that it is not. Yes, RBAC needs improvement. However, dropping the concept of role is exactly like throwing out the baby with the bathwater. The concept of role is the very thing that makes the policies manageable. I believe that the way how to improve RBAC is to make the roles smarter. The dynamics of ABAC and FBAC are indeed very useful. But they need to be combined with the manageability of the roles. And that’s exactly what good IDM systems do for more than a decade – long before the term ABAC was even coined. Even the first generation of the IDM systems had roles that were laced with some form of expressions. The second generation of IDM systems are taking that to the next level. For example the Hybrid RBAC model implemented in midPoint combines RBAC model with ABAC-like expressions. But we still hold fast to the crucial concept of role because we need manageability, accounting and identity governance.

Note: This post is mostly about ABAC. Some (but not necessarily all) of these issues are also applicable to FBAC and other models. For example the FBAC description mentions compilation of the access control policies. Which is a very good idea and it is used by almost all the existing IDM systems. FBAC seems to be generally an improvement over ABAC. But there are some issues that seems to be specific to either FBAC or the somehow implied by the FBAC description. More on that later.