RBAC vs. ABAC: What is the difference between access control models?

Close your eyes for a second (just kidding, you can’t do that and keep reading this) and imagine a perfect world. In this perfect world, you are tasked with creating an authorization system for your company. You need to specify a security policy that determines who can gain access to what in a system. No sweat. You’re in a perfect world, so only smart people who make no mistakes and have good intentions will use your system.

If only.

In the real world, you need to implement a hefty number of access controls. Access controls are what determine authorization (what you’re allowed to see and do in a system). Every access control has a few key elements:

• User — The entity trying to gain access (sometimes referred to as a subject when the “user” is actually a program or process).
• Resource — Document, data, or application being accessed.
• Operation — Functions that can be executed in the applications or on the resources once accessed.

Role-based access control (RBAC) and attribute-based access control (ABAC) are the two most commonly used access control models used for system authorization. Understanding the differences between the two is key for choosing between RBAC vs. ABAC for your system.

RBAC: Define access based on role

An RBAC system has a set of pre-defined roles set up by an administrator. Often, these roles will be akin to business terms, like “developer” or “accountant.” Each role has varying levels of permissions depending on job function.

‍

For instance, a developer should have access to code but doesn’t need to have access to other sensitive company information, like payroll. Going a level deeper, if you have Very Top Secret Code being developed on alongside your regular product (we’re looking at you, Apple), your roles may be more fine-tuned. Roles might be “machine-learning-developer” or “top-secret-developer.” Either way, each role has its own set of access rights and operational abilities. A manager or development department head might need to have access to not only code but also the payroll of the employees.

Authenticating users is a crucial first step which must be done before granting access. You can think of authentication as the first required operation, which can be attempted by anyone, but acts as a gateway for other operations and resources. (Confused about the differences between authentication and authorization? Check out our recent piece outlining them.)

Roles can be assigned to more than one user, and each user can have more than one role. Exactly how you decide to set that up to work in your system depends on the exact RBAC model you choose. The National Institute of Standards and Technology (NIST) has created a standard for RBAC models that outlines four different types of RBAC models: Flat RBAC, Hierarchical RBAC, Constrained RBAC, and Symmetric RBAC.

Each model in this list adds constraints and capabilities on to the previous model.

Flat RBAC: The basic model

With a Flat RBAC model, every user is assigned a role and every role is assigned specific permissions. For a user  to gain access to a file, that person must obtain a new role with permissions for that resource.

For example, a team manager of engineers would need the role of “developer” as well as the role of “manager” because they need to be able to see and edit code as well as higher-level things, like payroll and performance reviews.

Hierarchical RBAC: The scaling model

Remember, each new model holds the same constraints as the last one. So, along with Flat RBAC, Hierarchical RBAC adds a structure to the roles and configures relationships between the roles.

For example, a senior engineer role would include all permissions included in a lower-level engineering role, meaning the senior engineer can be unassigned from the previous role. The senior engineer role includes all permissions that the engineer needs for access.

Constrained RBAC: The verification model

Along with Flat and Hierarchical RBAC, the Constrained RBAC model adds in a separation of duties (SoD). This means that no one person can make certain kinds of changes without the approval of at least one other person.

For example, if a manager wanted to give one of their developers a pay raise, the adjustment would need to be approved by one other user with a role that can access payroll, like someone from HR. This helps prevent a rogue employee from making an accidentally disastrous (or malicious) change. So you’re going to have to actually work for that promotion, unfortunately.

Symmetric RBAC: The control model

The final level of NIST role-based access control models is the Symmetric RBAC. With Symmetric RBAC, permissions configured for each role are reviewed company-wide on a regular basis. Permissions can be revoked and reassigned by administrators as needed, which helps prevent role bloat (a common problem with RBAC).

As people move within the company — getting new jobs or promotions — they are assigned new roles without ever being un-assigned previous roles.

ABAC: Define access based on attributes

ABAC is a policy-based model that determines permissions based on attributes instead of roles. In general, there are user attributes, resource attributes, and environmental attributes (more on all of those in a minute). Administrators develop a security policy, generally with eXtensible Access Control Markup Language (XACML), that determines permissions by taking into account all related attributes.

For example, let’s take payroll as a resource. For a user to access this resource, there might be an attribute about their job function, like “role=HR,” and another attribute about where the user is accessing it from, like “location=office” or a specific IP address.

Using attributes instead of roles is a more detailed method of authorization. You can look into factors that can’t even be included in roles, like device type and time of day. The biggest downside of ABAC is that it can be extremely complex to set up the first time; however, once the security policy is written, there is very little additional work to do.

User attributes: Personal details

User attributes are details about each user. Yes, this can include role, so it can serve to partially function as RBAC. It also includes other attributes that are important for determining privileges in ABAC.

User attributes include:

• The user’s name
• ID
• Role
• Organization
• Team
• Security clearance

Let’s look at an example with restricted operations and resources based on “role” and “team” user attributes. If there’s a user with “role=engineering manager” (we’ll call her Alice), she’ll have access to payroll resources — not just any payroll resources, only the payroll resources related to her “team.” So the operation that allows Alice to view and edit payroll will allow her this functionality based on Alice’s “role” and then allow certain resources based on her “team” attribute.

Resource attributes: Object details

Resources have attributes too. With resource attributes, you can set up your security policy so that only owners of files can edit data within files, or only users with specific roles can access data with a certain sensitivity level.

Resource attributes include:

• The file’s name
• Creator
• Owner
• Date created
• Data sensitivity level

From the example above, Alice (an engineering team manager) was given access to an operation based on her “team” and “role.” The resource that Alice is attempting to view (payroll data) has its own attributes. Each file of payroll data belongs to a different team member, so it may have a “team” attribute (think of this as the file’s owner) that the security policy checks against Alice’s.

Environmental attributes: Real-time details

Environmental attributes look at conditions that are subject to change, such as time or device. They’re updated in real time and are an easy way to add security to sensitive data.

Environmental attributes include:

• Date
• Time of day
• Location of data
• Location of user
• Device
• Current detected threats to the organization

Alice’s company decided to add some extra security to their payroll resources and operations as the company grew. To do this, they added some environmental attribute checks to the security policy. Alice is only able to access her team’s payroll files between 8 am and 6 pm in her time zone and only from an approved device.

RBAC vs. ABAC: The best access model depends on company size and security needs

RBAC and ABAC are both valid ways to control access to data in your system. Which one works best for you will be based on a few things:

How big is your company? RBAC tends to not scale well because as more people and resources are added, more roles are created to define more detailed permissions. If you work at a big company, ABAC is probably the right move. Yes, it’s more complex to set up, but in the long run, it’ll be easier to maintain.

How complex does your authorization strategy need to be? In general, you should try to do the least complex form of access control possible. If RBAC will cut it, go for that. If you need more detailed permissions or to look at variables that fall outside of roles (like device type, location, or time), you’ll need to use ABAC.

The good news is that you don’t actually have to choose. You can use RBAC and ABAC in tandem. A common model is to begin with RBAC and keep it as an overarching access model, then slowly add ABAC on top to fine-tune security for various users, resources, and operations.