Jun 16, 2017

ABAC or RBAC

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

About the Author

Matt Schroeder profile.

Matt Schroeder

Director, Modern API

A wide range of professional experience and a Master’s Degree in Software Engineering have become the foundation that enables Matt to lead teams to the best solution for every problem.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Up to Spec: JavaScript Numeric Separators
Let's take a look at the proposal to add Numeric Separators to the JavaScript specification.
Using Conftest to Validate Configuration Files
Conftest is a utility within the Open Policy Agent ecosystem that helps simplify writing validation tests against configuration files. In a previous blog post, I wrote about using the Open Policy Agent utility directly to […]
SwiftGen with Image & Color Asset Catalogs
You might remember back in 2015 when iOS 9 was introduced, and we were finally given a way to manage all of our assets in one place with Asset Catalogs. A few years later, support […]
Tracking Original URL Through Authentication
If you read my other post about refreshing AWS tokens, then you probably have a use case for keeping track of the original requested resource while the user goes through authentication so you can route […]