The ability to control which user can do what is an essential part of any computing system. Once they are logged in, we will want to provide our users with mechanisms to restrict their access to specific resources based on the identity and the properties of the logged-in user. But how can we protect the routes? What level of authorization do we want to provide our users with? Should we base our authorization on roles, organization units, or locations? Let’s review the differences between the traditional RBAC and the more modern ABAC. We’ll also help you choose which one is right for you.
What does the RBAC model actually look like? Based on your role(s) in the organization, you need to gain access to specific resources and specific permissions within these resources. What does that look like to users? Every user is assigned to one (or more) roles and each role is assigned permissions (sometimes referred to as actions). This results in a matrix as you can see below:
The combination of having a user with several roles and the combination of permissions which can also belong to several roles leads to a flexible model that is often hard to manage.
This is the traditional way of doing RBAC, but there are more sophisticated approaches. These include:
Granular RBAC — for simple use cases, 2-3 basic roles and permissions will suffice. However, when approaching more complex scenarios, there is a need to set up additional “custom” roles. This can quickly lead to “role explosion”, which can result in manageability and security issues.
For example, you can deliver a SaaS application with “Admin”, “Maintainer” and “Operator” roles, while the SaaS customer can create 2 additional roles of “read-only” and “support” and define additional permissions for these roles.
In these cases, the APIs will need to be protected based on permissions and not roles, because roles in the system are dynamic.
Roles hierarchy —another common use case with roles is being able to provide a hierarchy for roles. In that case, if we decide that the “Team Leader” role is above the “Developer” role and “Team Leader” is blocked from certain permissions, we won’t allow this permission to be accessed by a lower level within the hierarchy.
Constrained RBAC – this is an RBAC model specially designed to handle the separation of duties (SoD). SoD is an organizational model in which the same individual should not be able to perform multiple parts of the same critical or sensitive activity. For example, an employee that creates purchase orders for suppliers should not also be able to sign the purchase orders and transfer the funds. Constrained RBAC assigns users to roles taking into account which roles can result in an SoD conflict.
Unlike RBAC, Attribute-Based Access Control (ABAC) takes into consideration other user attributes (where roles can be one such attribute, but not the only one).
When it comes to ABAC security, these attributes can include:
ABAC gives administrators fine-grained control over user access. They can define multiple attributes, and give the same person different permissions depending on their current security context. For example, an employee working on their secure corporate workstation in the office could have one level of permissions, while the same employee connecting from their mobile device will have different permissions.
Administrators use if/then statements to define access rules in ABAC. For example, an administrator can specify that if users are in the finance department, they can access financial documents; if users have a manager role, they have broader read/write permissions; and if an access attempt occurs outside business hours, it is denied.
ABAC allows the administrator to combine all of these criteria and more to create complex business rules. All ABAC attributes are being processed by an authorization engine that evaluates and allows/denies the operation requested by the user.
The architecture will look like this (in most cases):
Now that we’ve covered the basics, let’s dive into the comparisons.
RBAC is the most common way to restrict access. The main benefit of this model is that an organization does not need to individually approve or revoke access, but instead group users by role. In a large company, defining roles can become a major challenge. Many organizations experience “role explosion”, with roles defined by multiple groups becoming unmanageable and creating security issues.
The RBAC model also has other limitations:
The main advantage of ABAC is that it grants access based on the properties of each system component rather than the user’s role. In this way, you can write complex business rules. For example, you can specify that certain employees can access specific data remotely only during business hours. ABAC rules can also evaluate new properties that were not originally known when the approval system was set up.
ABAC limitations include:
Enterprises typically start with a flat RBAC implementation. This model is easy to set up and maintain. As organizations develop and manage more sensitive data, they realize the need for more sophisticated access control systems. RBAC and ABAC can be used together – RBAC does the coarse work and ABAC complements it with finer filtering. The combined model is known as RBAC-A.
There are several ways to implement RBAC-A in an organization:
The best access control model to use depends on your company size and organizational structure. The following table summarizes possible use cases.
As mentioned above, it is common to combine RBAC and ABAC. All the above scenarios could also be implemented by combining RBAC and ABAC, and this will usually provide greater flexibility.
NIST has recently released the open-source Policy Machine which implements a new type of access control known as Next Generation Access Control (NGAC). It is based on ABAC but allows the use of multiple access control methods at the same time, to enable different treatment of on-premise and cloud environments. NGAC addresses the challenges of both RBAC and ABAC:
NGAC uses the concept of graphs to manage access in a simple, centralized way. It scales linearly at any organization size and does not suffer from performance problems. Its greatest benefit is flexibility – it can allow access based on object attributes, time, location, or any other criterion. Another unique feature of NGAC is that it supports just-in-time access – for example, it can grant a contractor one-time access to a resource for maintenance, and then automatically revoke access.
NGAC uses several types of entities that represent protected resources and the actors that need to access them:
NGAC essentially creates a graph that models the resources you want to protect and the organizational structure in a way that is meaningful to each organization. Based on this customized model of the organization, administrators can add access policies and permissions.
The world of handling permission-based access control models in SaaS applications is a complex one and requires a deep understanding of the use cases and the different approaches that can help resolve this challenge. The simple RBAC can work for the first version. However, with enterprise deals, we will need to pay attention to granular roles and permissions and hierarchies (for the advanced complex RBAC) and sometimes to advanced environment-related attributes (with the use of ABAC).
There’s no clear winner in this battle because each methodology has its own inherited benefits. With user behavior becoming more and more dynamic in nature, you need a versatile solution that doesn’t push you into one corner. Are open-source tools the solution? Not really.
At Frontegg, we took all of these into consideration when building our SaaS-as-a-Service platform, which will provide you with added implementation flexibility as an end-to-end user management solution. Have some questions on what is the correct model for you and how you should implement it? Feel free to reach out. We are here to help you.
Start For Free
