Role Based Access Control (RBAC) has been around since the 1970s  and continues to be a well-accepted industry standard. However, with the arrival of Attribute Based Access Control (ABAC) many companies are shifting their views so that they can take advantage of the granular level of authorization that ABAC can provide.
Before getting deeper into why ABAC may or may not fit your needs, let’s first step back and define each.
Role based security relies on the grouping of users into various roles which are then assigned rights. A right is typically made up of an action and a resource type (ex. right => Create Document, right => Update User). Every user in a particular role can perform the same set of rights on the system. It’s a simple premise and does the job for many applications. The main issue arrives when systems progress and admins want more fine-grained rules, resulting in an excess of roles (i.e. role explosion). As roles get created to fit each one-off use case, the security of the system can become unwieldy to manage and even harder to test. This can leave unknown vulnerabilities in a system.
Enter Attribute Based Access Control, a solution that allows you to enforce security decisions based on any attribute accessible to your system and not just the user’s role. This could be an attribute of the user (subject), the action that the user is performing, a value of the resource they’re trying to manipulate or retrieve, or even an environment variable. The combination of these four things allows for policies to be set up that are as fine-grained as you desire.
ABAC achieves this flexibility through these major components:
This sounds like a great way to approach security, but there are valid reasons that this approach may not fit all needs or is simply overkill.
1. KISS – sometimes less is more. If you can fit all users into 3 roles, great! ABAC should really only be used if you’ve come up with a set of policies that go beyond “role xyz can do a, b, and c”. Here are a few examples of when ABAC may be useful when trying to enforce policies.
2. With great power comes great complexity. Without good management of the policies the system will be enforcing, it (“attribute explosion”) can become even worse than role explosion.
3. Due to the architecture of an ABAC system and the number of components required to make it run, it can be costly to build and costly to buy.
4. With all new things comes training. If an RBAC system seems to be working, why spend the money on training people to build, manage, and support a new shiny ABAC system.
5. A combination approach may be better than shoehorning one solution into the other. Maybe for certain pieces of a system, RBAC fits the build but for another section, ABAC is critical to meet business requirements. Keeping a clean divide between these may allow for a successful overall security solution.
Looking for more information on ABAC? Comment below for additional posts you’d like to see.