Difference between RBAC, ABAC and PBAC

RBAC, ABAC and PBAC are three different Access Control methods that can be seen as successive developments within the IAM field. RBAC, ABAC and PBAC are access control methods for automatically determining which employees should be given which access rights, and each method takes a different approach. Automating identity and access management based on these methods is important, because manually managing access rights for every individual user in an organisation is impractical. These structured approaches are achieved through RBAC, ABAC, and PBAC. Below, we explain how each method works, highlight the differences between them, and discuss the advantages of each method. We also provide concrete examples of how these methods are applied within a modern IAM platform like HelloID. But first, let’s briefly explore the history of these access control methods.

The origins of RBAC, ABAC and PBAC

To understand the differences between methods, it is useful to first look at their origins and how they have evolved over time.

The beginning: IBAC

The most basic way of organising access management is Identity-Based Access Control (IBAC). This approach involves creating a list of access rights for each individual user. The need for this already arose with mainframe computers where multiple users had access to one central computer system and administrators wanted to prevent users from interfering with each other on the system. With a limited number of users and at most a few shared facilities, a simple list of identities and access rights like this was sufficient.

The transition to RBAC

As networks grew in size and complexity, with more users and applications, managing individual access rights for every user became too complex. This led to the introduction of Role-Based Access Control (RBAC) around 1992. With RBAC, users are granted access to IT resources based on their role within the organisation. This simplified management because everyone with a certain role automatically gets the same rights. Instead of managing access rights for each individual user, you manage them per role.

The origins of ABAC

RBAC works well in organisations where there is a clear one-to-one relationship between roles and rights. But there were also organisations that clearly required more flexibility. In response, Attribute-Based Access Control (ABAC) was developed in the late 1990s. With ABAC, access rights are assigned based on various characteristics (attributes). These can still be someone's role but also, for example, someone's department or expertise. In this sense, RBAC can be seen as a subset of ABAC, which is broader, more flexible, and more powerful.

The evolution to PBAC

While ABAC introduced greater flexibility, it also made managing the relationships between attributes and access rights very complex. This led to the development of Policy-Based Access Control (PBAC). PBAC focuses on ease of use by defining access policies in clear, natural language rather than complex structures or code. This allows organisations to create and modify access rules themselves more easily and quickly. Access rights are still granted based on attributes, but PBAC uses straightforward policy rules to manage them. You can also add process rules and workflows more easily.

Attributes for access control

Attributes are characteristics of users and their sessions. Typically, these attributes are categorised into three types:

User attributes: These are attributes related to the user itself. Examples of user attributes are the user's name, department, their regular work location, specific competences, etc.
Object attributes: These attributes are properties or characteristics of, for example, 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) and helps determine which specific resources a user is allowed to access
Contextual attributes: This category of attributes concerns operational, technical and sometimes situation-specific context in which the access occurs. Examples of contextual attributes include the date and time of an access attempt, but also the access location or network, the status of the system or device used.

Examples of RBAC vs ABAC vs PBAC

Let's put theory into practice. Below are some examples of how to apply RBAC, ABAC and PBAC in practice.

Example RBAC (Role-Based Access Control)

RBAC grants access based on the role(s) a user has within an organisation. 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 Associate’, ‘IT Administrator’ and ‘Nurse’ are defined. Users such as Jan, Sara, Mike and Lisa are assigned to these roles and given the corresponding access rights.
Example:

Jan is a Finance Manager and is allowed to edit financial reports and view personnel files.

Sara is an HR Associate and is allowed to view personnel files, but not edit them.

Mike is an IT Administrator and has access to IT systems, but no access to financial reports or personnel files.

Lisa is a Nurse and is allowed to view patient records and edit vital records.

Advantages: This model is easy to understand and implement, especially in organisations with a stable structure. It provides clarity on who has what access.
Disadvantages: RBAC is less flexible with changing or complex access needs. If changes are needed, roles have to be modified or new roles created, which can lead to an excessive number of roles and can make management complex.

Example ABAC (Attribute-Based Access Control)

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

Definition and setup: Attributes may relate to the user's position, department and working location (user attributes), file type and information sensitivity (resource attributes), time and location of access (contextual attributes). Business rules are created that combine these attributes to make access decisions.
Example:

Jan is allowed to edit confidential financial reports if he works in the Finance Department, is a Manager and it is within office hours.

HR Associates like Sara are allowed to view but not edit personnel files, regardless of the time of day.

Lisa, a Nurse, is allowed to view a patient's records if she is the attending care provider, it is within her duty hours and she requests access from within the hospital network.

Advantages: ABAC offers a high degree of flexibility and fine-grained control. Access can be dynamically adjusted based on current attributes, making it suitable for organisations with complex and changing access needs.
Disadvantages: ABAC requires a more detailed management of attributes and the careful creation of rules. Rules are often created using programming code such as XACML, which requires more time and technical expertise.

Example PBAC (Policy-Based Access Control)

PBAC determines access based on centrally managed policies that combine attributes and logic. These policies are written in clear, natural language, making management easier and more accessible. For example:

Definition and setup: Policies are created that clearly specify who has access to what, under what circumstances. These rules combine attributes with specific conditions and are managed centrally
Example:

Policy 1: Financial managers are allowed to edit confidential financial reports during office hours.

Policy 2: HR associates are allowed to view personnel files, but not edit them.

Policy 3: Attending healthcare providers are allowed to view and update medical records of their assigned patients during their duty hours.

Policy 4: All access to patient records must take place within the hospital network.

These policies are written in natural language and centrally managed. This makes them easier to understand and adapt.

Advantages: PBAC combines the flexibility of ABAC while simplifying management. Policies can be created and modified faster, because they are written in natural language. This is even the case for people without in-depth technical knowledge. The centralised management of policies makes it easier to maintain consistency and respond quickly to changes.
Disadvantages: A well-designed and managed policy system is required. If too many policies are created or if they are not managed properly, the system can become complex and difficult to oversee.

RBAC vs ABAC

What is the difference between RBAC and ABAC?

The main difference between RBAC and ABAC is the way in which access is granted. In RBAC, you can grant access by directly assigning a role to a user. In ABAC, you can dynamically determine access based on user attributes, object attributes and contextual attributes.

ABAC vs PBAC

What is the difference between ABAC and PBAC?

The difference between ABAC vs PBAC is in how you can configure the rights model. In ABAC, role attributes are configured using specialised markup languages like XACML. In PBAC, they are defined in the form of simple policies written in natural language. While PBAC is not necessarily more powerful than ABAC, it is significantly easier to use.

Summary

In summary, these are the key differences:

RBAC is suitable for simple, stable environments but lacks flexibility.
ABAC offers great flexibility and fine-grained control, but is more complex to manage.
PBAC combines the flexibility of ABAC with simpler management by using centrally defined policies in an easy-to-understand language.

Importantly, the differences between ABAC and PBAC do not lie in the use of attributes. In PBAC you also use one or more attributes, but you have a more user-friendly approach to manage your access rights,[] we will illustrate this below using the HelloID platform.

RBAC, ABAC and PBAC within your IAM platform

Many IAM platforms support RBAC, but as discussed, this approach has its limitations. That's why we built a more advanced mechanism for HelloID that allows us to offer a combination of RBAC, ABAC and PBAC. In doing so, you can use all available information about users, their context and their requests. However, to keep the system workable and accessible, HelloID treats user attributes differently from the context and resource attributes:

The values of user attributes are relatively static. A person's job title, department and similar details do not change on a daily basis. This makes them ideal for use within the HelloID Provisioning Module to automatically determine which accounts and access rights employees need. Once or twice a day, the system refreshes users' accounts and access rights and transfers the changes to the relevant target systems such as Active Directory, TOPdesk and business applications.
Context attributes and resource attributes are not about users but about individual user sessions, and these values change on a session-by-session basis. Since they are dynamic, they cannot be used for provisioning user accounts and rights Instead, we use those context and resource dependencies to further refine access rights. For example, an access rule might specify that permissions are valid only during office hours. In this way, we can make access control context- and resource-dependent when needed.

In short, the automated provisioning of user accounts and their rights to target systems is done using user attributes. We can refine specific access rights using context attributes and resource attributes. This is how we support full ABAC and PBAC. We will explain this further below.

Provisioning Based on User Attributes

In provisioning, the big difference between RBAC and ABAC lies in the available user attributes. Pure RBAC only works with roles, while with ABAC you have many more attributes at your disposal, such as the department, division, work location and competences. These attributes can also be combined. This allows you to organise your rights management much smarter and simpler. For instance, you can build a smart ‘rights pyramid’:

Some permissions are required by every employee. For instance, in many organisations, all users receive an email account and a Microsoft 365 licence. With ABAC, these can be automatically assigned across the entire organization to every user. This eliminates the need to manually link these rights to every individual role, as would be necessary with RBAC.
You can provide certain permissions based on a person’s department or team. An example is a departmental SharePoint share. You grant it based on the department where people work. Again, individual roles do not matter here.
In most cases, this leaves you with only a limited number of rights that you really need to link specifically to someone's role. Like a healthcare employee who needs to be given specific rights in the healthcare system. Only those rights will be provided based on individual roles.

This illustrates the power of ABAC. With attributes like roles, departments, teams, locations or competences, you can very easily select other and larger groups within your organisation to whom you can assign the same rights at once. With RBAC, this is not really possible or it quickly gets very complicated.

From ABAC to PBAC with business rules

But how can you also easily set up and manage this attribute-based model? You don't want to rely on a scripting tool or other complex methods to manage your ABAC settings. This is where business rules come into play within HelloID. In a business rule (also called a policy rule), you can clearly define which permissions should be assigned based on specific user conditions. In a healthcare institution, for example, a business rule could look like this:

If an employee has the position ‘Healthcare Helper Level 4’ and works in the Care A department (the condition), by default, they will be given an Entra ID account + an account in the Electronic Client File with rights for clients in Care A (the corresponding permissions).

As we mentioned earlier, we can refine those permissions using context attributes and resource attributes. In a healthcare system, for example, you can set which client groups are accessible, whether people are only allowed to view data or also edit it, and from which network. Each application has its own configuration options, and HelloID's extensive connector catalogue makes it easy to integrate various target systems and automatically assign the correct permissions.

By applying business rules, we establish a PBAC (Policy-Based Access Control ) model, which offers significant advantages. Thinking in terms of policies simplifies access management Administrators do not need to understand the underlying relationships between attributes and permissions. Instead, they can simply create rules that apply to all users, specific departments, roles, or other user attributes as needed. You can also easily add all kinds of conditions to permissions.

Any potential overlap between business rules is not an issue. The system translates all defined rules into a consistent, coherent permission model. An additional advantage is that business rules also allow you to add additional policies and workflows. For example, a rule that accounts for new employees must be activated a week before on-boarding. Or that certain application permissions may only be activated once users have accepted the terms of use online.

Find out more about RBAC, ABAC and PBAC

Want to know more about how to practically apply the above for your identity and access management? In our webinar, we provide a detailed explanation of how to build your permission structure using roles and other attributes. You will also see how you can use role mining to analyse and further optimise your existing permission structure.