Role Based Access Control (RBAC) has been around since the 1970s [1] 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.

RBAC

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.

ABAC

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:

• Policy Decision Point (PDP) – the “brain” of the system. The PDP receives a XACML request, processes the request, and returns a decision of whether or not the user should be able to proceed.
• Policy Information Point (PIP) – the PDP utilizes PIPs to pull in any information that is needed to make a decision. A PIP may talk to active directory or a database to look up user details or even call an external API to fetch data that will help make the decision.
• Policy Enforcement Point (PEP) – these are the gateways to the system that intercept requests and call the PDP to make sure the user can proceed. If the PDP says “DENY”, the PEP is the one that enforces that decision.
• Policy Administration Point (PAP) – most of the out of the box solutions have a UI to help users configure their policies.

ABAC for the win, right?

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.

• Only the user that created the record can delete the record.
• Users can only view documents in the state or country that they are working in.
• A manager can only edit user information for individuals one level below them.

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.

Footnotes

1. History of RBAC