Three RBAC policy challenges that can be solved with ABAC

David Brossard   ·   Thursday, September 14th, 2023

When using a role-based access control (RBAC) model organizations can run into different challenges as they scale.

Roles are static and provide a coarse-grained approach to access control, which puts various limitations on what can be done with them.

This approach can also lead to role explosion and other issues when the organization tries to scale and add more fine-grained elements into their access control strategy.

Attribute-based access control (ABAC) addresses these issues as it provides a more dynamic, fine-grained approach to access control. This enables you to extend your RBAC strategy and consider other attributes in addition to roles.

As ABAC relies on various attributes, including roles, that are involved in the access control process to express authorization policies and enforce access control requests.

Here are three of the challenges that we often hear from organizations looking to build on their RBAC model with ABAC.

1. Relationships can’t be expressed

When leveraging a traditional RBAC model, you cannot express the relationships between roles.

This is because roles do not consider other attributes and are only a static way to distinguish which users should have authorization to access certain information.

Through ABAC, you are able to define relationships between roles (attributes) with policies.

For example, if a relationship can’t be expressed, a user may not be able to view documents within their own department. This is because a role does not contain enough information to complete this access control request, it would require another attribute, like their department, to complete the request.

Not only that but, you can use the relationship between roles to add segregation of duties (SoD) functionality. With this in place, an approver cannot approve a purchase order that they created themselves.

When using RBAC, there can be a lot of ad hoc requests that have to be addressed or completed manually in order to add roles, entitlement and/or update and amend policies. Whereas with ABAC, the number of these requests are considerably fewer.

2. When only using roles they lose their meaning

When only using roles, the roles start to lose their meaning.

Organizations often end up adding so many roles to address a broad number of access requests that a role is no longer a ‘role’ – it is an access request that was created as a role so it can be governed within the RBAC model.

Roles become meaningless as it is a way to try and force-fit an ABAC approach into a RBAC model.

However with ABAC, organizations can express access requests so that roles maintain their meaning along with other attributes.

3. RBAC makes recertification an ongoing, time-consuming process

Recertification is an RBAC approach because the decisions are static so they must be reviewed periodically (quarterly or even monthly) to ensure the access granted is still warranted, used or useful to the user.

This process can include managers/app owners/department heads and require them to go into a governance solution portal. From there they have to ‘attest’ or ‘recertify’ entitlements depending on if that employee should still have that access.

Beyond a sizeable financial investment, this process can eat up a lot of resources as it takes many days to complete and is often done in siloes.

This is because the process often includes tedious, manual tasks including entering and reviewing data in spreadsheets or applications that may or may not be connected to an identity governance and administration (IGA) solution.

Additionally, all of these spreadsheets and applications are managed by different people in different departments, adding to the consuming process of consolidating the data to capture a complete view of everything.

Recertification with RBAC is also a static process. This means that if there are any changes that happen even a few hours after the process, that recertification is now inaccurate and unsecure.

For organizations using ABAC, recertification isn’t as critical because the ABAC solution makes access decisions in real-time at the point of access based on the attributes collected at that exact moment.

As it runs continuously in the background, the solution makes changes to what access the user can have immediately instead of having to wait until the next time the recertification process is completed.

This means an ABAC approach  not only saves an organization a lot of time, but it also makes applications more secure.

The Axiomatics difference

For more than 15 years, Axiomatics has delivered runtime, fine-grained authorization with ABAC. We have worked with some of the world’s largest and most complex organizations to modernize their approach to access control and authorization.

As a part of that approach we use a policy-first authorization language that has the structure to scale as your organization grows.

This is because our Orchestrated Authorization solution provides the structure that holds all of the policies and elements in place so it is easier to view and manage the policies efficiently.

Our policy editor also allows your teams to write the policies in line with other critical daily activities, ensuring access and security initiatives do not inhibit their work to deliver quality applications on time and under budget.

This is accomplished as we enable development teams to write policies in regular language within their daily workflow.

Take the next steps

Learn more about how Axiomatics can help you extend your RBAC strategy with ABAC by downloading our white paper.

Request a demo and talk with our solution experts about how ABAC can build on your organization’s RBAC model.