RBAC VS ABAC: Pros, Cons, Choosing the Right AuthZ Policy Model

Authorization is a complex challenge that basically every developer building an application has to face. As a software product grows, the need to grant or deny access to specific resources based on a user's verified identity becomes critical (It’s also important not to confuse Authentication, which is verifying a user's identity, with Authorization).

At the end of the day, it's crucial that we make sure The right people have the right access to the right assets. This is what authorization is all about.

Application-level Authorization can be managed through different authorization models. These authorization models determine the level of access or permissions granted to users based on factors such as user roles, attributes, contextual information, or a combination of these factors.

Choosing the right authorization model and properly implementing it is not an easy task, and it is critical to maintaining the security and privacy of an application, its users, and its data.

To make this decision easier, we’ll review two of the most common authorization models - Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC), the main differences between them, and when they should be applied.

Let’s start with RBAC -

What is RBAC

Role Based Access Control (RBAC) is an authorization model used to determine access control based on predefined roles. Access permissions are assigned to roles like “Admin” or “Editor”. Then, roles are assigned to specific users by the administrator.

This structure allows you to easily understand who has access to what based on these defined roles.

For example, here’s a rather simple example of an RBAC policy in simple English -

Employees can View and Edit Documents, while Admins can View, Edit, Create, and Delete them.

RBAC provides a rather simple solution for controlling access to resources based on a predefined set of roles that can, for example, correlate with an individual's job function or responsibilities.

RBAC Pros

Simplicity: RBAC provides a solution that is rather simple and familiar to both your developers and end-users while allowing for more granular access control than basic models like Admin/Non-Admin.
Easy management: The predefined roles set by RBAC can, for example, correlate with an individual's job function or responsibilities. This can allow administrators to manage access control at a high level by defining roles and assigning them with permissions rather than managing permissions for individual users.
Scalability: RBAC enables developers to scale rather easily as their application grows. If implemented correctly, adding or removing roles and permissions can be a simple task, making it easier to support a growing number of users, roles, and resources efficiently.

RBAC: Cons

Implementation complexity: While less complex than ABAC, RBAC can still be quite challenging to implement, especially in large and complex applications that require support for a large number of roles and users. Designing and implementing RBAC requires a thorough understanding of the application's requirements and the roles and permissions needed to support them. It is crucial to follow established best practices when doing so.
Limited flexibility: As user access is defined solely by roles and not specific attributes, an RBAC system can quickly become insufficient when new, more granular access control requirements emerge.

So how is ABAC any different? Let’s dive into it -

What is ABAC

While RBAC determines access based on predefined roles, Attribute Based Access Control (ABAC) is all about conditional attributes. These allow for a much more fine-grained way of managing access control.

Attributes can contain a vast number of parameters, 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, etc.

For example, here’s an 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.

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:

Employees - a Role
Based in the European Union - a User Attribute

The same goes for the Resource:

Document - a Resource
GDPR Protection - a Resource Attribute

To learn more about ABAC and its implementation methods, check out this guide.

ABAC provides us with the ability to create highly granular, complex, and detailed authorization policies, which can be based on varying user and resource attributes.

ABAC: Pros

Fine-grained: ABAC provides the ability to create extremely fine-grained access control policies with its use of attributes. This becomes an ever-growing requirement as policies for billing (e.g. "only users who paid for a feature can use it"), location, time, trust level, quotas, anomaly, fraud, and risk profiles are becoming basic requirements.
Highly Dynamic: It is very often that applications rely on abilities that have to be managed in a real-time fashion. If implemented using the right tools, ABAC can provide dynamic access control based on real-time changes in user/resource attributes. Perfect examples of this are the need for attributes such as time, a user’s geolocation, payment status, etc.

ABAC: Cons

Complexity: ABAC can be a huge challenge to implement, manage, and maintain. Not only can it be very complex and time-consuming to design, but it's also an ongoing endeavor.

Authorization doesn’t stop at the point of implementation, and it needs to be managed and adapted to the needs of the application as it changes and grows. It is absolutely crucial to provide both your developers and relevant stakeholders with an accessible way to manage and maintain their ABAC policies.
Resource-intensive: As ABAC potentially requires taking a very large number of attributes into account, it can be very resource-intensive, requiring more processing power and time.
Difficult to audit: ABAC can be difficult to audit because access control decisions are based on complex policies that may be difficult to understand. This challenge can be addressed by using an authorization service that allows easy access to audit logs for both RBAC and ABAC.

Now that we have reviewed both policy models, how would we know which one is more suitable for our needs?

Making a choice: RBAC vs. ABAC

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.

While keeping things rather simple, RBAC lacks flexibility as user access is defined solely by roles and not specific attributes.

ABAC provides a more in-depth approach, allowing you to add attributes into the mix and create much more granular, dynamic access control. That being said, ABAC can require more processing power and implementation 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.

If implementing and maintaining authorization wasn’t complex enough, creating a structure that allows you to switch from one model to another or use them together can be even more daunting. An easy solution to this complexity is picking an authorization solution that adheres to authorization best practices and is flexible and accessible.

Scalable Implementation

Authorization requirements tend to grow exponentially along with the application. The requirement to shift from hardcoded Admin / Not admin rules into RBAC and ABAC can happen extremely fast. As various requirements from customers, security, compliance, and 3rd party integrations come in, you might need to refactor your entire authorization system every 3-6 months.

Setting up a system as complex as ABAC could take months of work, which doesn’t end at the point of implementation - as creating additional roles, attributes, and policies requires complex R&D work and steep learning curves.

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.

The solution is implementing and managing your RBAC and ABAC policies using an authorization service that allows for flexible transition between authorization models and provides a simple no-code UI that makes permission management accessible to other stakeholders.

That’s where Permit comes in -

Permit - RBAC and ABAC with a no-code UI

Permit provides developers with a permission management solution that allows for both smooth transitioning from RBAC to ABAC, and the ability to create and manage policies using an accessible no-code UI.

Permit’s UI generates Rego code for both RBAC and ABAC (See links for code examples), wrapping it nicely into Git, and API / UI interfaces which you can edit, add to, and manage however you like.

This allows both developers and other stakeholders to set up RBAC policies and add complex attributes and conditions - all without having to write a single line of code.

Setting up an ABAC policy with Permit's UI is as easy as checking a box

Implementing authorization with Permit ensures that everyone is included in the permission management process, preventing developers from becoming bottlenecks while also allowing a smooth transition between RBAC and ABAC.

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