This article provides an understanding of RBAC vs. ABAC. Learn what each of these are, what they do, and how they work. The differences between RBAC and ABAC will be explained and the pros and cons of each will be discussed.
What is RBAC?
Role-based access control (RBAC) is a cybersecurity solution that protects IT resources (e.g., data, cloud systems, servers, databases, clusters, and networks) from unauthorized access by systems or users. RBAC’s approach permits access and actions (e.g., read, write, or share) according to a user’s role, and any user assigned a role has the privileges. Separate roles are created for all users to access different resources, and users can be assigned multiple roles.
Core elements of RBAC systems include:
- Administrators—identify roles, grant permissions, and manage the RBAC system
- Roles—users are grouped together based on the tasks they perform
- Permissions—actions assigned to each role that dictate what users can and cannot do (e.g., access, read, write, share, or delete)
Roles can be defined by:
- Authority, such as an administrator, a specialist user, an end-user, a director, a manager, or an intern
- Competence, such as a skilled worker vs. a novice
- Responsibility, such as a board member vs. the CEO, where both are at the same level in an organization’s hierarchy, but would have different access privileges based on their responsibilities
Examples of roles for RBAC access control policies include:
- Accounts payable (e.g., the user responsible for handling billing)
- Administrative (e.g., users that perform administrative tasks)
- Primary (e.g., the primary contact for a specific account or role)
- Technical support (e.g., users that perform help desk requests)
What is ABAC?
Like RBAC, attribute-based access control (ABAC) is a cybersecurity solution that protects IT resources (e.g., data, cloud systems, servers, databases, clusters, and networks) from unauthorized access by systems or users.
Considered an evolution from RBAC, ABAC evaluates characteristics, rather than roles, to establish access privileges.
It uses Boolean logic to grant or deny access to users based on dynamically evaluating attributes and the relationship between them and granting access.
The combination of attributes used by ABAC to control access includes the following.
ABAC action attributes
ABAC action attributes describe the action associated with the system or application being accessed (i.e., what the user is trying to do with the resource or object). In complex cases, multiple attributes can describe an action.
ABAC action attributes used to validate access requests include:
- Approve
- Copy
- Delete
- Edit
- Read
- Transfer
- View
- Write
ABAC environmental or contextual attributes
ABAC environmental or contextual attributes indicate the broad context in which access is requested, such as:
- Access location
- Aim of access
- Communication protocol
- Encryption strength
- Normal behavior patterns
- Number of transactions made within the past 24 hours
- Relations with a third party
- Subject’s device (e.g., laptop, tablet, or phone)
- Threat levels
ABAC resource or object attributes
ABAC resource or object attributes describe the access target. The characteristics of resources or objects include:
- All identifying resource or object properties, such as its creation date, ownership, file name and type, and data sensitivity
- Resource or object type, such as a file, application, server, or application programming interface (API)
ABAC subject or user attributes
ABAC subject or user attributes are often gathered from authentication tokens during login, human resources systems, or user directories. These attributes describe the user attempting to access a resource.
ABAC subject or user attributes can include the following information about a user:
- Age
- Departmental and organizational affiliations
- Group memberships
- Job roles
- Job title
- Management level
- Name
- Nationality
- Organization
- Security clearance
- User ID
Differences between RBAC and ABAC
Role-based access control and attribute-based access control (ABAC) differ in their approaches.
| RBAC | ABAC |
| -Grants access according to predefined roles, such as administrator or manager -Manages broad access -Considers attributes, such as job titles and seniority | -Grants access according to attributes related to the user, environment, actions, and resources -Manages fine-grained access -Considers attributes, such as user types, time of day, and location |
RBAC vs ABAC pros and cons
An evaluation of RBAC vs. ABAC reveals a number of pros and cons, including the following.
| RBAC vs. ABAC—RBAC Pros | RBAC vs. ABAC—RBAC Cons |
| The most commonly cited pro of RBAC is simplicity, with roles being simple and easy to execute. Other pros of RBAC include: -Administration work is quick. -RBAC requires minimal processing power. -Access hierarchies can be created (e.g., managers are automatically granted all of the rights of their direct reports). -RBAC implementations are usually low. | The most commonly cited con of RBAC is role explosion, where more roles have to be added to create full access. Other cons of RBAC include: -RBAC requires collaboration across departments. -Administrators must have a clear understanding of business and the infrastructure that supports it. It can be complicated to translate user requirements to roles. -Administrators sometimes assign people to ill-fitting roles or add new roles contrary to policy, which results in privilege creep, role explosion, and security gaps. |
| RBAC vs. ABAC—ABAC Pros | RBAC vs. ABAC—ABAC Cons |
| The most commonly cited pro of ABAC is well-defined control. Other pros of ABAC include: -Administrators can define, enhance, and manage many variables, which delivers a high level of control. -Very specific and granular access control policies can be developed. -Administrators can select from a large set of attributes when formulating rules. -Existing rules do not need to be modified to accommodate new users or use cases. -No need to modify existing rules to accommodate new users. | The most commonly cited con of ABAC is the time required to support it. Other cons of ABAC include: -Defining variables and configuring access control policies is a significant effort, especially when starting out. -There are limited resources with the expertise needed to manage ABAC solutions. -ABAC systems can be difficult and time-consuming to manage. -Granularity creates complexity. |
When to use RBAC vs ABAC
Typical implementations for when to use RBAC vs. ABAC are as follows.
Use RBAC for organizations with these characteristics:
- Small- and medium-sized enterprises with few external users
- Access control policies can be broad
- Roles are clearly defined
Use ABAC for organizations with these characteristics:
- Large enterprise with many distributed users
- Deep, specific access control capabilities are needed
- Robust access control is needed to meet compliance requirements
Using both RBAC and ABAC
For enterprise organizations with the resources, RBAC and ABAC’s combined strength can be a powerful defense against cyber threats. Although RBAC and ABAC function differently, they can be used together. Administrators can assign static access to specific resources to a role with RBAC, while using dynamic access policies to create and enforce granular controls with ABAC.
