Article

RBAC vs ABAC: Definitions and differences

Access ManagementSecurity
Time to read: 4 minutes

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:

  1. Administrators—identify roles, grant permissions, and manage the RBAC system
  2. Roles—users are grouped together based on the tasks they perform
  3. 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:

  1. Authority, such as an administrator, a specialist user, an end-user, a director, a manager, or an intern
  2. Competence, such as a skilled worker vs. a novice
  3. 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:

  1. Accounts payable (e.g., the user responsible for handling billing)
  2. Administrative (e.g., users that perform administrative tasks)
  3. Primary (e.g., the primary contact for a specific account or role)
  4. 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:

  1. Approve
  2. Copy
  3. Delete
  4. Edit
  5. Read
  6. Transfer
  7. View
  8. Write

ABAC environmental or contextual attributes

ABAC environmental or contextual attributes indicate the broad context in which access is requested, such as:

  1. Access location
  2. Aim of access
  3. Communication protocol
  4. Encryption strength
  5. Normal behavior patterns
  6. Number of transactions made within the past 24 hours
  7. Relations with a third party
  8. Subject’s device (e.g., laptop, tablet, or phone)
  9. Threat levels

ABAC resource or object attributes

ABAC resource or object attributes describe the access target. The characteristics of resources or objects include:

  1. All identifying resource or object properties, such as its creation date, ownership, file name and type, and data sensitivity
  2. 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:

  1. Age
  2. Departmental and organizational affiliations
  3. Group memberships
  4. Job roles
  5. Job title
  6. Management level
  7. Name
  8. Nationality
  9. Organization
  10. Security clearance
  11. User ID

Differences between RBAC and ABAC

Role-based access control and attribute-based access control (ABAC) differ in their approaches.

RBAC vs ABAC pros and cons

An evaluation of RBAC vs. ABAC reveals a number of pros and cons, including the following.

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:

  1. Small- and medium-sized enterprises with few external users
  2. Access control policies can be broad
  3. Roles are clearly defined

Use ABAC for organizations with these characteristics:

  1. Large enterprise with many distributed users
  2. Deep, specific access control capabilities are needed
  3. 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.

Smart, scalable, seamless identity security

Trusted by 48% of the Fortune 500

Mark and Sumit

S1 : E2

Identity Matters with Sumit Dhawan, Proofpoint CEO

Join Mark McClain and Sumit Dhawan to understand the future of cybersecurity and how security teams can support CISO customers in the midst of uncertainty.

Play podcast
Mark and Ron

S1 : E1

Identity Matters with Ron Green, cybersecurity fellow at Mastercard

Join Mark McClain and Ron Green to understand the future of cybersecurity and the critical role identity security plays in safeguarding our digital world.

Play podcast
Dynamic Access Roles

Dynamic Access Roles

Build the next generation role and access model with dramatically fewer role and flexibility

View the solution brief