Difference Between RBAC, ABAC, and PBAC

RBAC, ABAC, and PBAC are three different access control methods that can be viewed as successive generations within the IAM domain. They automate decisions about which employees should receive which access rights, and each method uses a different approach. Automated identity and access management based on such methods is important because you do not want to manage every access right individually and manually. You need a structured approach, which RBAC, ABAC, and PBAC provide. Below, we explain how these methods work, how they differ, and the benefits of each. We also provide concrete examples and show how they are used in a modern IAM environment such as HelloID. We start with the history behind these access methods.

Origins of RBAC, ABAC, and PBAC

To understand the differences between the methods, it is useful to first look at their origins and evolution.

The Beginning: IBAC

The most basic way to organize access management is Identity-Based Access Control (IBAC). You record a list of access rights for each user. This need arose with mainframe computers, where multiple users accessed a single central system, and administrators wanted to prevent users from interfering with one another. With a limited number of users and only a few shared resources, such a simple list of identities and access rights is adequate.

The Shift to RBAC

As networks grew in size and complexity, it became too complex to manage individual access rights for everyone. This led to the introduction of Role-Based Access Control (RBAC) around 1992. Users receive access to IT resources based on their role within the organization. Administration became simpler because everyone in a given role automatically received the same permissions. You no longer manage access rights on a per-user basis; instead, you manage them on a per-role basis.

The Emergence of ABAC

RBAC works well in organizations where there is a clear one-to-one relationship between roles and rights. However, some organizations required more flexibility. Therefore, Attribute-Based Access Control (ABAC) was developed in the late 1990s. In ABAC, access rights are assigned based on attributes. That can still include a role, a department, or competencies. From that perspective, RBAC is a subset of ABAC; ABAC is broader, more flexible, and more powerful.

The Evolution to PBAC

ABAC provides flexibility, but it quickly becomes complex to structure and manage all the dependencies between attributes and a person’s rights. This led to the development of Policy-Based Access Control (PBAC). PBAC emphasizes ease of use by defining access policies in clear, natural language rather than complex structures or code. As a result, organizations can create and modify access rules more easily and quickly. Rights are still granted based on attributes, but simple policy rules govern them. You can also add process rules and workflows more easily.

Access Control Attributes

Attributes are characteristics of users and their sessions, and we often distinguish three types of attributes:

• User Attributes: Attributes that relate to the user. Examples include the user’s name, department, regular work location, specific competencies, and so on.

• Object Attributes: Properties or characteristics of applications, web services, or data that the user requests access to. An example of such an object or resource attribute is the sensitivity level (public/confidential/secret), which helps determine which specific resources a user may access.

• Contextual Attributes: This category covers the operational, technical, and sometimes situation-specific context in which access occurs. Examples include the date and time of the access attempt, the access location or network, the system status, or the device used.

Examples of RBAC vs ABAC vs PBAC

Let us make the theory concrete. Below are examples of how to apply RBAC, ABAC, and PBAC in practice.

Example RBAC (Role-Based Access Control)

RBAC grants access based on the roles a user holds within an organization. Users are assigned to specific roles, and each role has predefined rights and permissions. For example:

• Definition and Setup: In RBAC, roles such as "Finance Manager", "HR Staff", "IT Administrator", and "Nurse" are defined and configured. Users such as Jan, Sara, Mike, and Lisa are assigned to these roles and receive the corresponding access rights.

• Example:

• Advantages: This model is simple to understand and implement, especially in organizations with a stable structure. It provides clarity about who has which access.

• Disadvantages: RBAC is less flexible for changing or complex access needs. If changes are required, roles must be adjusted or new roles created, which can lead to role explosion and complicated administration.

Example ABAC (Attribute-Based Access Control)

ABAC grants access based on attributes of users, resources, actions, and the environment. These attributes are evaluated to determine whether access should be granted. For example:

• Definition and Setup: Attributes can relate to the user’s job function, department, and work location (user attributes), file type and information sensitivity (resource attributes), and the time and location of access (contextual attributes). Business rules are created that combine these attributes to make access decisions.

• Example:

• Advantages: ABAC offers high flexibility and granular control. Access can be dynamically adjusted based on current attributes, making it suitable for organizations with complex, evolving access needs.

• Disadvantages: The system is more complex to implement and manage. It requires extensive attribute management and careful rule definition, often using policy markup languages such as XACML, which demands more time and technical expertise.

Example PBAC (Policy-Based Access Control)

PBAC determines access based on centrally managed policy rules that combine attributes and logic. These policies are written in clear, natural language, which makes administration simpler and more accessible. For example:

• Definition and Setup: Policy rules specify who has access to what and under what conditions. These rules combine attributes with specific conditions and are centrally managed.

• Example:

• Advantages: PBAC combines the flexibility of ABAC with simpler administration. Because policies are written in natural language, they can be created and adjusted more quickly, even by people without deep technical knowledge. Central policy management makes it easier to maintain consistency and respond quickly to change.

• Disadvantages: It requires a well-designed and well-managed policy system. If there are too many policies or if they are not managed properly, the system can become complex and hard to oversee.

RBAC vs ABAC

What is the Difference Between RBAC and ABAC?

The main difference between RBAC and ABAC is how each method grants access. With RBAC, you grant access by assigning a role to a user directly. With ABAC, you dynamically determine access based on user, object, and contextual attributes.

ABAC vs PBAC

What is the Difference Between ABAC and PBAC?

The difference between ABAC and PBAC lies in how you configure the authorization model. With ABAC, you configure role attributes using specialized policy markup languages such as XACML. With PBAC, you configure them as simple policy rules in natural language. PBAC is therefore not necessarily more powerful than ABAC, but it is much easier to use.

Summary

In short, these are the differences:

• RBAC is suitable for simple, stable environments but lacks flexibility.

• ABAC offers significant flexibility and granular control, but is more complex to administer.

• PBAC combines ABAC’s flexibility with simpler administration by using centrally defined policies in clear language.

It is important to note that the differences between ABAC and PBAC are not in the use of attributes. PBAC also uses one or more attributes, but offers a more user-friendly way to manage access rights. We illustrate this below using the HelloID platform.

RBAC, ABAC, and PBAC Within Your IAM Platform

Many IAM platforms support RBAC, but we have observed limitations. That is why HelloID includes a more advanced mechanism that combines RBAC, ABAC, and PBAC. You can use all available information about users, their context, and their requests. To keep this workable and accessible, HelloID uses user attributes differently from context and resource attributes:

• The values of user attributes are relatively static. A person’s job function, department, and so on do not change daily. They are therefore ideal for use in the HelloID Provisioning Module to automatically determine which accounts and access rights employees need. Once or twice a day, the system refreshes user accounts and access rights and propagates changes to target systems, including Active Directory, TOPdesk, and business applications.

• Context attributes and resource attributes are not about users; they are about individual user sessions, and their values vary per session. We therefore cannot use them for provisioning user accounts and rights. Instead, we use those contexts and resource dependencies to further refine access rights. For example, you can add a condition to an access right so that it applies only during business hours. This is how we make access context- and resource-dependent, where needed.

In short, we automatically provision user accounts and associated permissions on target systems based on user attributes. We can refine specific access rights using context attributes and resource attributes. This is how we support full ABAC and PBAC. We explain this further below.

Provisioning Based on User Attributes

For provisioning, the key difference between RBAC and ABAC lies in the set of user attributes available. Pure RBAC uses only roles, whereas ABAC provides many more attributes, such as department, division, work location, and competencies, which you can also combine. This allows you to organize access rights much more intelligently and simply. For example, you can build a smart access rights pyramid:

• Every employee needs some rights. In many organizations, everyone receives a mail account and a Microsoft 365 license. With ABAC, you grant those automatically across the organization to all users. You therefore do not need to link these rights to all existing roles as you would with RBAC.

• Other rights can be granted at the department or team level. An example is a SharePoint department share. You grant that based on the department where people work. Individual roles do not matter here either.

• You often end up with only a limited set of rights that should be tied to a person’s role. For example, a healthcare worker must receive specific rights in the EHR. Only those rights are granted based on individual roles.

This illustrates the power of ABAC. Using attributes such as roles, departments, teams, locations, or competencies, you can easily select larger groups across your organization and assign the same rights to them at once. RBAC cannot do this easily, or it becomes very complicated.

From ABAC to PBAC with Business Rules

How can you configure and manage an attribute-based model in a simple way? You do not want a scripting tool or another complex method to manage your ABAC settings. HelloID uses business rules for this. In a business rule, you can easily describe which rights or permissions should be assigned under which specific user conditions. In a healthcare organization, such a business rule might look like this:

If an employee has the job function ‘Care Assistant Level 4’ and works in department Care A (the condition), they receive by default an Entra ID account plus an account in the Electronic Client Record with rights for clients in Care A (the corresponding permissions).

As noted earlier, we can refine those permissions based on context attributes and resource attributes. In a healthcare system, you can configure which client groups are accessible, whether data may be viewed only or also edited, and from which network. Each application offers different configuration options, and HelloID provides an extensive connector catalog to connect target systems and automatically assign the appropriate permissions.

Using these business rules, we implement a PBAC model with a major advantage. Thinking in policy rules is simple, and administrators don't need to understand the underlying structure linking attributes to rights. You can easily add rules that apply to all users, specific departments, roles, or other user attributes. You can also add various conditions to permissions. Any overlap between business rules is not a problem; the system translates all entered rules into a consistent, coherent rights structure. An added benefit is that you can extend policy rules and workflows via business rules. For example, a rule that accounts for new employees must be activated one week before onboarding. Or that some application rights may become active only after users have accepted the terms of use online.

Learn More About RBAC, ABAC, and PBAC

Want to learn how to apply the above in practice for your identity and access management? In our webinar, we provide an in-depth explanation of how to build your access rights structure using roles and other attributes. You will also learn how to use role mining to analyze your existing rights structure and further optimize it.

Watch it Here

[1] https://www.jstor.org/stable/10.2307/26486786

[2] https://dl.acm.org/doi/abs/10.1145/3007204

[3] https://link.springer.com/chapter/10.1007/978-3-030-04834-1_2

[4] https://ieeexplore.ieee.org/abstract/document/4470448