RBAC and ABAC: The access control models you should know

Role-based access control (RBAC) and attribute-based access control (ABAC) are two of the most popular access control models. In this post, we will give a brief overview of both models and discuss their differences.

---

Introduction

Access control is a critical aspect of security in any system. It ensures that only authorized users can access resources and perform actions. Role-based access control (RBAC) and attribute-based access control (ABAC) are two of the most popular access control models used in modern systems. Both models are widely adopted and can be used to enforce access control policies effectively. But what are they and how they differ?

Role-based access control (RBAC)

RBAC was first introduced in the early 1990s. The formalization of the model is credited to David Ferraiolo and Rick Kuhn in a paper published in 1992. Since then, RBAC has become one of the most widely used access control models in the industry.

In RBAC, access control policies are based on roles, which are collections of permissions. Users are assigned roles (e.g., administrator, editor, viewer), and their access rights are determined by the permissions (e.g., create, edit, delete) for specific resources (e.g., files, databases, applications). It simplifies the management of access control policies by grouping users based on their roles and assigning permissions to roles. It is straightforward to add or remove users from roles, and the changes will be automatically reflected in the access control policies.

Key components of RBAC

• Resource: A resource is an entity that a user can access. Resources can be anything from files, databases, APIs, or any other system entity that needs to be protected.
• Permission: A permission is a specific action that a user can perform on a resource. For example, create, edit, delete, view. The definition of permissions may vary depending on the system. In most of the cases, permissions are defined at the level of the resource with a minimum granularity.
• Role: A role is a collection of permissions that define a set of actions that a user can perform. For example, an administrator role may have permissions to create, edit, and delete resources, while a viewer role may have permission to view resources.
• User: A user is an entity that can be assigned one or more roles. Users are granted access to resources based on the permissions associated with the roles they are assigned.

Pros of RBAC

• Simplicity: RBAC is easy to understand and implement. Assigning permissions to roles and roles to users is straightforward.
• Efficiency: It simplifies the management of access control policies by grouping users based on their roles. It is easy to add or remove users from roles without changing the access control policies. Especially in large organizations with well-defined permission structures, RBAC can be very efficient.
• Transparency: RBAC provides a clear mapping between roles, permissions, and users. It is easy to audit and review access control policies.

Cons of RBAC

• Rigidity: RBAC can be rigid when it comes to defining complex access control policies. It may not be suitable for systems where access control policies need to be more dynamic and context-aware.
• Granularity: RBAC may lack the granularity required for fine-grained access control. The access control policies are tied up to well defined roles, and it may require extra effort to define permissions at a more granular level.
• Role explosion: In large organizations with complex permission structures, the number of roles can grow exponentially, leading to role explosion. Managing a large number of roles can be challenging.

Attribute-based access control (ABAC)

In the late 2000s, as systems became more complex and dynamic, more and more organizations started to adopt attribute-based access control (ABAC) as an alternative to RBAC. A notable milestone in the formalization of ABAC is the publication of the NIST Special Publication 800-162 in 2014.

ABAC is a more flexible access control model compared to RBAC. It is an authorization model that defines access control policies based on the attributes of the user, resource, action and environment. It allows organizations to define fine-grained access control policies that can adapt to different contexts and conditions.

Key components of ABAC

• Subject: A subject is an entity that requests access to a resource. It can be a user, a device, an application, or any other entity that needs to access resources.
• Resource: Just like in RBAC, a resource is an entity that a subject can access. Resources can be files, databases, APIs, or any other system entity.
• Action: An action is a specific operation that a subject can perform on a resource. It can be create, read, update, delete, or any other operation that needs to be controlled.
• Environment: The environment is the context in which the access request is made. It can include attributes such as time of day, location, network, device, etc.
• Attribute: An attribute is a characteristic of a subject, resource, action, or environment. Attributes can be anything from user roles, department, location, IP address, device type, etc.
• Policy: A policy is a rule that defines the conditions under which access is granted or denied. Policies are defined based on the attributes.

Pros of ABAC

• Flexibility: ABAC can accommodate complex access control policies that are based on multiple attributes. It allows organizations to define fine-grained policies that can adapt to different contexts and conditions.
• Dynamic: ABAC policies can be dynamic and context-aware. Access control decisions can be made based on real-time attributes such as location, time of day, device type, etc.
• Granularity: ABAC provides fine-grained access control by allowing organizations to define policies based on multiple attributes. Unlike defining roles and permissions, attributes based policies can be more granular.

Cons of ABAC

• Complexity: ABAC can be more complex to implement and manage compared to RBAC. Defining attributes and policies can require more effort and expertise. Unlike RBAC, where roles and permissions are well-structured, attributes can be more dynamic and so dose the policies. Managing a large number of attributes and policies in a complex system can be challenging. A centralized policy evaluation engine is often required to evaluate the policies.
• Performance: Attribute evaluation can impact performance, especially in real-time environments. Policies based on multiple attributes and real-time conditions can introduce latency in access control decisions.

Comparison table

From the comparison table, it is clear that RBAC is best suited for systems with well-defined permission structures and where access control policies are relatively static. On the other hand, ABAC is more suitable for systems where access control policies need to be dynamic, context-aware, and fine-grained.

Examples

Scenario: A hospital system that need to manage access to patient records for different staff members.

• Staff: Doctors, Nurses, Administrators
• Resources: Patient records
• Permissions: Read, Write, Delete

Case 1

The access control policies are relatively simple:

1. Doctors can read and write patient records.
2. Nurses can read patient records.
3. Administrators can read, write, and delete patient records.

RBAC model

In this case, RBAC is simple and effective. We can define roles for doctors, nurses, and administrators, and assign the appropriate permissions to each role.

The access control evaluation is straightforward:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

ABAC model

In this case, ABAC may be an overkill, but it can still be used to define fine-grained policies based on attributes such as department, role, etc.

Attributes:

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

Policies:

• Policy 1: Allow read access based on user.role and resource.name

  • subject: User with role doctor, nurse, admin
  • resource: Resource with name patient-record
  • action: read
  • effect: allow
  • rationale: "Allow read access to patient records for all roles"

• Policy 2: Edit Access for doctors and admins

  • subject: User with role doctor, admin
  • resource: Resource with name patient-record
  • action: write
  • effect: allow
  • rationale: "Allow write access to patient records for doctors and admins"

• Policy 3: Delete Access for admins

  • subject: User with role admin
  • resource: Resource with name patient-record
  • action: delete
  • effect: allow
  • rationale: "Allow delete access to patient records for admins"

For each read/write/delete request, the policy engine evaluates all the relevant policies based on the attributes and makes an access control decision.

Case 2

Same hospital system, now lets introduce a new role patient and a new attribute patient-id.

The access control policies are:

1. Doctors can read and write patient records.
2. Nurses can read patient records.
3. Administrators can read, write, and delete patient records.
4. Patients can read their own records.

RBAC model

In this case, apart from the old read permission, we need to introduce a new permission read-own. We can define roles for doctors, nurses, administrators, and patients, and assign the appropriate permissions to each role.

Now the access control evaluation is a little bit more complex, especially for the read patient record action:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

ABAC model

Now let's update the attributes and policies in the ABAC model to accommodate the new requirements.

Attributes:

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

Policies:

• Policy 1: Allow read access to all patient records

  • subject: User with role doctor, nurse, admin
  • resource: Resource with name patient-record
  • action: read
  • effect: allow
  • rationale: "Allow read access to patient records for all staffs and patient himself"

• Policy 2: Allow write access to all patient records for doctors and admins

  • subject: User with role doctor, admin
  • resource: Resource with name patient-record
  • action: write
  • effect: allow
  • rationale: "Allow write access to patient records for doctors and admins"

• Policy 3: Allow delete access to all patient records for admins

  • subject: User with role admin
  • resource: Resource with name patient-record
  • action: delete
  • effect: allow
  • rationale: "Allow delete access to patient records for admins"

• Policy 4: Allow read access to own patient records

  • subject: User with role patient
  • resource: Resource with name patient-record
  • action: read
  • condition: user.id === resource.patient-id
  • effect: allow
  • rationale: "Allow read access to own patient records"

Conclusion

Now let's take a deep look at the above two cases.

In the first case, the access control policies are simple and well-structured. It only requires a single level permission check to determine whether a user has access to a resource. Imagine the hospital system has a more complex structure with multiple departments, roles, and permissions. In a RBAC model, the access control evaluation process of the patient records resource will still remain simple and straightforward, whether the user has the read, write, or delete permission. ABAC, on the other hand, need to involve additional attributes like department-id and doctor-id. What if a IoT device that needs to access the patient records? It will require a new attribute device-id to be introduced in the policy evaluation. How about granting the read permission temporarily to an intern doctor?
In the second case, the access control policies are more complex and context-aware. The access control evaluation process of the patient records resource will require multiple levels of permission checks to determine whether a user has access to a resource. An extra level of resource attribute patient-id is introduced in the policy evaluation. In an RBAC model, we have to introduce a new permission read-own to accommodate the new requirement, plus an extra comparison logic to evaluate the ownership of the patient record. A simple permission check is no longer sufficient.The access control evaluation process will become more complex. In this case, ABAC is a better fit. ABAC allows organizations to define fine-grained policies based on multiple attributes and conditions. Imagine the hospital system has more complex and granular access control over the patient records, such as different access levels for different departments and doctors. A doctor can only access the patient records of his/her department. Patient records can only be accessed using a hospital internal IP address. This may increase the complexity of defining and managing the access control policies in a RBAC model significantly. ABAC might be a better choice this time.

The choice between RBAC and ABAC depends on the specific requirements of the system. RBAC is best suited for systems with well-defined permission structures and where access control policies are static. ABAC is more suitable for systems where access control policies need to be dynamic, context-aware, and fine-grained. In practice, organizations may choose to use a combination of both models to achieve the desired level of access control.

Try Logto Cloud for free