What is ABAC? Implementation Methods & Code Examples

When building an application, there is one crucial thing we have to make sure of: 
The right people have the right access to the right assets. This is what authorization is all about.  There are different authorization models (RBAC, ABAC, ReBAC, etc.) and different ways to implement them. 

We have already written about Role-Based Access Control (RBAC), and how it can be implemented using Open Policy Agent (OPA) and Permit.io. This time, we will dive deeper into the waters with Attribute Based Access Control (ABAC).

What is ABAC

While RBAC is an authorization model that determines access based on predefined roles (Like Admin, Editor, and Viewer, for example), Attribute-Based Access Control (ABAC) is all about - 
You guessed it, attributes. 

ABAC is an authorization model that determines access based on conditions applied to attributes (or characteristics), rather than roles, allowing the definition of fine-grained complex access-control rules.  

Sounds complex? Let’s look at an example:

ABAC Example

Here’s a rather simple example of an ABAC policy in simple English - 

Employees that are based within the European Union can perform any action on a GDPR Protected Document.

Let’s dive into this - the policy, as any authorization policy, can be divided into three parts:

Who can perform which Action on which Resource 

In this example, the question ‘Who?’ can be answered by:

1. Employees - a Role 

2. Based in the European Union - a User Attribute

The same goes for the Resource: 

1. Document - a Resource

2. GDPR Protection - a Resource Attribute

Now that we've reviewed a simple example, let’s get into why you should (Or shouldn’t!) choose ABAC as the policy model for your application. 

ABAC Pros

Generally, ABAC provides you with highly granular policy creation.

It provides a complex and detailed authorization method, with the ability to factor in a great number of variables, such as a user’s role, security clearance, time of access, location of the data, current organizational threat levels, resource creation date or ownership, data sensitivity, and many more. 

Each of these provides a wider, more detailed spectrum of parameters for deciding on a user’s range of access.

ABAC Cons

While providing you with the capability for creating highly granular authorization policies - ABAC is not for everyone. ABAC requires more processing power and time and can be harder to design and implement. Additionally, the challenge of getting all the relevant attribute data into your decision point in time can be daunting as well (though this can be elevated by tools like OPAL).

RBAC provides a simple solution for determining authorization, which is usually sufficient for most organizations. In some cases, when a more in-depth approach to authorization is required, ABAC may be the best option.

ABAC vs RBAC

ABAC and RBAC are two of the most common authorization policy models. So how should you decide between them? In short - the choice between the two depends on the needs of your organization, and the application you are building. 

RBAC provides a rather simple solution for determining authorization - Only a person with the role of X can perform action Y on resource Z. It’s simple, and is usually sufficient for most organizations.

ABAC provides a more in-depth approach, allowing you to add attributes into the mix and create much more granular access control. That being said, ABAC can require more processing power and time - so it's important to strike a balance, so your authorization policy is neither too simplistic nor too complex.

In many cases, RBAC and ABAC can be used together hierarchically, with broad access enforced by RBAC protocols and more complex access managed by ABAC. 

Organizations often start by implementing their own RBAC, and then gradually evolve it into ABAC as additional attributes are required. When dynamic data points such as time, location, billing status, and current behavior come into effect - ABAC is unavoidable.

A more detailed overview of RBAC vs ABAC is available here.

Implementing ABAC

Before we deal with implementing ABAC, we need to address two important challenges with implementing authorization policies in general -

1. Each service in your application must be configured with its own set of policies manually. This can quite a hassle - as the number of policies, users, and services grows, updating the policies in each relevant service can become very tedious and time-consuming. Considering the fact that policies change all the time - they have to be at least somewhat fluid. 

2. Mixing the code of the authorization layer into the application code is a bad idea for several reasons. In general, this can make it difficult to upgrade, add capabilities, and monitor the code as it is replicated between different microservices. Each change would require us to refactor large areas of code that only drift further from one another as these microservices develop. 

Both of these issues can be solved by creating a separate microservice for authorization, and thus decoupling our policy from our code. Controlling access management centrally through a separate authorization service allows you to offer it as a service to every system that needs to check whether a user can or cannot access its resources. This can be done by using Open Policy Agent (OPA). 

Let’s review a quick example of how an ABAC policy would be expressed with OPA.

ABAC Example with OPA

Using OPA’s Rego policy language, the example ABAC policy that we created above would look like this (Try it out in the OPA playground):

package abac

# User attributes
user_attributes := {
    "User1": {"location": "EU", "title": "employee"},
    "User2": {"location": "US", "title": "employee"},
    "User3": {"location": "EU", "title": "manager"}
}
# Document attributes
document_attributes := {
    "Doc1": {"classification": "GDPR Protected"},
    "Doc2": {"classification": "Non-sensitive"}
}
# Default deny
default allow = false
# EU employees can perform any action on GDPR Protected Document
allow {
    # Lookup the user's attributes
    user := user_attributes[input.user]
    # Check that the user is an employee
    user.title == "employee"
    # Check that the employee is based in the EU
    user.location == "EU"
    # Check that the document is GDPR Protected
    document_attributes[input.document].classification == "GDPR Protected"
}
# Allow any employee to access non-GDPR-protected documents
allow {
    # Lookup the user's attributes
    user := user_attributes[input.user]
    # Check that the user is an employee
    user.title == "employee"
    # Lookup the document's attributes
    document := document_attributes[input.document]
    # Check that the document is not GDPR Protected
    document.classification = "Non-sensitive"
}

To learn more about implementing ABAC with OPA’s Rego, check out this guide. 

When is OPA not enough?

While OPA provides us with the ability to unify all policies in one server, take on the role of policy decision-making and enforcement from the service, and manage policy as code, it lacks several key functionalities, most importantly:

The ability to create, manage and enforce ABAC Rego policies in a way anyone in your organization can use.

Rego is a powerful language, but not an easy one to learn, let alone master. Being a derivative of Datalog, it can prove as a struggle even for skilled engineers.

Normally, creating and managing your application’s authorization policies could only be done through complex R&D work and steep learning curves (e.g. writing Rego code). This creates a situation where developers become bottlenecks in your app’s permission management, other stakeholders are locked out of the conversation, and your customers are left without the flexibility they require. All of these manifest as an unending stream of feature requests.

The solution is implementing and managing your RBAC and ABAC policies with a simple no-code UI which makes permission management accessible to other stakeholders. 

That’s what Permit is here for - 

Permit - a UI for managing ABAC

Permit provides developers with a permission management solution that makes policy-as-code as easy as checking a checkbox - generating the needed code for you, and wrapping it nicely into Git, and API / UI interfaces. 

Here’s what our example ABAC policy would look like within Permit’s UI: 

In the UI, selecting which user has access to a resource is as simple as checking a box. 

Let’s review the basic steps of creating this policy within Permit’s UI:

1. Create a User Role titled “Employee”
   

   

2. Create a “location” attribute with a string type
   

   

3. Create a “User Set” titled “EU_Employees”, for which the conditions are:

• “user.location” = “EU”

• “user.roles” contains “Employee”
  

4. Create a resource titled “document1” and add a boolean attribute to it called “GDPR” 

5. Finally, create two “Resource Sets”: 

• One titled “GDPR_DOC” with the condition of resource.GDPR = True

• One titled “NON_GDPR_DOC” with the condition of resource.GDPR = False

6. Once everything is set up, enforcing access control is as simple as checking a few boxes:

Permit’s concepts of User-Sets and Resource-Sets (aka Condition-Sets), allow users to manage complex ABAC systems with ease without having to write a single line of code. The UI generates Rego code into a Git repository of your choice, which you can edit, add to, and manage however you like. Striking a crucial balance between developer and customer needs.

This structure also allows you to transition from RBAC to ABAC smoothly and use complex attributes and conditions on them as if they were RBAC roles. 

An in-depth tutorial on setting up ABAC policies with the Permit UI is available here: 

Easily create ABAC policies with the Permit UI - Tutorial

What wev'e learned

Let’s go over everything we learned about ABAC: 

• ABAC is an authorization model that determines access based on attributes, allowing the definition of fine-grained complex access-control rules.

• ABAC provides you with highly granular policy creation, but it can be harder to design and implement. 

• RBAC provides a rather simple solution for determining authorization which is usually sufficient for most organizations. ABAC provides a more in-depth approach, allowing you to add attributes into the mix.

• RBAC and ABAC can be used together hierarchically, with broad access enforced by RBAC protocols and more complex access managed by ABAC.

• As each service in your application must be configured with its own set of policies manually, updating the policies in each relevant service can become very tedious and time-consuming. To avoid this, we can create a separate microservice for authorization using OPA.

• While OPA provides us with the ability to unify all policies in one server, take on the role of policy decision-making and enforcement from the service, and manage policy as code, it lacks the ability to create, manage and enforce ABAC Rego policies in a way anyone in your organization can use.

• Permit’s no code UI allows you to create both RBAC and ABAC policies, and include other stakeholders in the permission management process, preventing developers from becoming bottlenecks. It also allows a smooth transition between the two using complex attributes and conditions as if they are RBAC roles. 

Want to learn more about Authorization? Join our Slack community, where there are hundreds of devs building and implementing authorization.