Role Based Access Control (RBAC) vs Attribute Based Access Control (ABAC) for API Authorization

Amit Kanfer April 7, 2021

We’ve been hearing a lot about zero-trust security lately. More teams are managing applications and systems that support zero-trust security framework and instituting this structure is becoming more common within dev, security and IT teams.  At its core, zero-trust security is built upon the principles of authentication and authorization. If you have a handle on the what, when, where, and how users (both human and non-human entities) flow through authentication and authorization, you’ve already made progress toward achieving zero-trust security, fundamentally speaking.

So, what are authentication and authorization? In simple terms, authentication is the verification of the user’s identity against whom they claim to be. Authorization is granting a certain level of user permissions to that verified user to determine what access they should have to different resources. 

This article will examine the two core access control principles: role based access control (RBAC) and attribute based access control (ABAC). In addition to briefly introducing each of these control types, we will also discuss their distinct differences, advantages and what scenarios are more appropriate for each.  

What is RBAC and ABAC?

Role-Based Access Control (RBAC)

In RBAC, access is determined by the role of the requester. Typical RBAC would entail roles like user, manager, admin or super admin.

For example, if you are a developer in the IT department, you will only get access to the employee self-service portal within your company’s human resources management system. But if you are the payroll manager in the finance department, you will have access to both the employee self-service portal and the payroll management module. If you are the HR manager, you will have access to all of the modules within the system. With RBAC, roles are largely determined by hierarchy, department, location, or job responsibilities within an organization.

You can implement RBAC on four levels as the National Institute of Standards and Technology (NIST) guidelines.

1. Flat RBAC

Flat RBAC offers the most fundamental implementation model. In this model, there are three entities including users, roles, and permissions. You can assign employees or users to roles such as administrator, auditor, or manager through the role assignment. You can also modify the permissions tied to these roles through the permission assignment.

There can be many-to-many role assignments as well as many-to-many permission assignments. Additionally, users can also use permissions of multiple roles at the same time.

2. Hierarchical RBAC

Hierarchical RBAC, as its name indicates, provides the ability to create a hierarchy of the roles you have created, define the relationship between roles and how they inherit permissions from one another. Roles at the top of the hierarchy have a significant number of more permissions compared to those of junior roles.

3. Constrained RBAC

When you introduce separation of duties (SoD) to the hierarchical RBAC model, the result is constrained RBAC. Separation of Duties means no single user can commit a single workflow alone, thus requiring multiple users and multiple roles to complete a single workflow. Constrained RBAC helps to substantially minimize fraudulent activities.

4. Symmetric RBAC

Symmetric RBAC is the highest level of RBAC, including all the features of constrained RBAC while offering the ability to support permission-role reviews. Periodic permission reviews should conducted for each and every role in the system to promptly revoke excessive permissions tied to those roles.

Attribute-Based Access Control (ABAC)

The Attribute-Based Access Control leverages attributes as opposed to a role in order to control access to a system or resource. This access control model is also known as Policy-Based Access Control because we use policies that combine attributes together that adds a guardrail to your access management.

The ABAC model uses attributes such as the job title, department of the user-attributes category, file type, file creator, data classification belonging to the resource-attributes category,  time, date or location to define the access control policies. ABAC can offer contextual access control based on almost any attribute from any source. This might include the status of a ticket in Jira, the status of an opportunity in Salesforce or virtually any other attribute from any data source. 

For example, if the system administrator sets ‘role must equal HR Executive’ and ‘department must equal HR’ on the permission to access attendance records in an HRMS, a user from the marketing department would not be able to access the attendance records. Here, the attribute value that we change is the location department. Similarly, you can restrict ‘view’ permissions to a file labeled ‘sensitive’ using an ABAC policy that sets the attribute value for ‘data classification’ attribute as ‘sensitive’.

The following table compares RBAC to ABAC.

Characteristic

RBAC

ABAC

Complexity RBAC rules are simple and easy to establish and maintain within a small company, whereas it is hard and complex to maintain within a larger company. RBAC policies require lower processing power and time. Defining  ABAC policies requires a significant effort. Policies can easily be maintained and supported. ABAC policies also require higher processing power and time.
Scalability

X

Flexibility

Support for Rules Supports both simple and complex rules, except for rules with dynamic parameters Supports both simple rules and complex rules, as well as dynamic, data driven attributes.
Cost Establishing RBAC rules incur lower costs. But, the ‘role explosions’ that often come with RBAC can incur significant costs to maintain. Defining ABAC policies at the outset can consume resources and thus  incur higher costs. f Successfully implementing ABAC policies can lowers costs in the long run.
Granularity Coarse-grained access control Fine-grained access control

 

When to use RBAC and When to use ABAC?

Now that you know what RBAC and ABAC are, and what the pros and cons of each of these access control models are, it’s important to evaluate the an access control mechanism that is most suitable to your system and its business requirements..

So what are the best scenarios to apply RBAC?

  1. For small organizations with basic permission structures: If you are managing 20-50 users in a  RBAC is much easier to set up and manage.
  2. For organizations with role-based hierarchy: Generally, if the access control policies within your organization are defined by  job roles within your organization and are not task-based, RBAC may be an adequate control for the systems regardless of the size of your organization.e. However, if your organization is a larger-scale enterprise, business rules usually demand more sophistication quickly so we highly recommend that you apply symmetric RBAC.
  3. For simple and non-business critical applications: RBAC is effective and can easily be set up for simple applications. If the application isn’t mission-critical and you’re not dealing with access to potentially sensitive data, RBAC can usually

And what are the best scenarios to apply ABAC?

  1. Companies with offices in multiple locations or a large, distributed workforce: Companies with virtual employees or  geographically distributed offices and networks require to control access to systems based on the time zone, geographical location, network connection (VPN), etc. You can control these attributes when you implement an attribute-based access control policy, something you aren’t able to do with RBAC.
  2. Organizations that require dynamic controls. Regardless of the size or scale of your company or its systems, many companies need to create authorization rules based on properties from external data sources. If you want to create a rule whereby a user only has access to your system if their Account Status in Salesforce equals Customer, RBAC isn’t going to cut it. If your requirements depend on looking at data sources from other services, you’re likely going to need ABAC out of the gate. The general rule of thumb is to start with RBAC, and if needed, move to ABAC, but ultimately RBAC is a static framework that can’t support these dynamic, contextual business rules. Building access controls that can’t support your business requirements is going to likely be a waste of time and resources.

ABAC  can be universally applied to any technology stack and infrastructure including, firewalls and servers (the network layer), the application layer, and the data layer. Many enterprises find that a hybrid approach between these two control models is a suitable way to manage identity and access management. 

Subscribe to build.security’s newsletter

Keep up with the latest news on our authorization policy management platform