Jun 16, 2017


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.


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:

  • 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.


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
Google Professional Machine Learning Engineer Exam 2021
Exam Description A Professional Machine Learning Engineer designs, builds, and productionizes ML models to solve business challenges using Google Cloud technologies and knowledge of proven ML models and techniques. The ML Engineer is proficient in all aspects […]
Designing Kubernetes Controllers
There has been some excellent online discussion lately around Kubernetes controllers, highlighted by an excellent Speakerdeck presentation assembled by Tim Hockin. What I’d like to do in this post is explore some of the implications […]
React Server Components
The React Team recently announced new work they are doing on React Server Components, a new way of rendering React components. The goal is to create smaller bundle sizes, speed up render time, and prevent […]
Jolt custom java transform
Jolt is a JSON to JSON transformation library where the transform is defined in JSON. It’s really good at reorganizing the json data and massaging it into the output JSON you need. Sometimes, you just […]