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 is RBAC (Role Based Access Control)?
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.
Types of RBAC
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.
What is ABAC (Attribute Based Access Control)?
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:
- The “Who” (user attributes)— such as name, email, role, organization, country
- The “Where” (environment attributes) — such as the origin of the request, the user-agent on the browser etc.
- The “What” (resource attributes) — Such as the owner of the resource that we are trying to access, the time it was created and so on.
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):
RBAC vs. ABAC: Pros and Cons
Now that we’ve covered the basics, let’s dive into the comparisons.
RBAC Pros and Cons
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:
- Rules cannot be set with parameters unknown to the system.
- Permissions can only be assigned to user roles, not objects or actions.
- You can also use RBAC to restrict access to specific operations on the system, but not to specific data
ABAC Pros and Cons
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:
- Due to the way policies are specified and maintained, ABAC restrictions are difficult to configure.
- ABAC has low visibility – it is difficult to conduct an audit to see what privileges a particular user has.
- It can be difficult or even impossible to determine the risk exposure for a particular employee or organizational role.
Combining RBAC and ABAC
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:
- Using the RBAC role as one of the user attributes in ABAC. The “role” attribute is then used to indicate a set of required attributes for that organizational role.
- Adding attributes to constrain roles, so that RBAC defines basic access control rules, and ABAC reduces permissions available to a user depending on specific criteria.
- Setting dynamic roles, where the RBAC role is determined according to other attributes defined in ABAC. For example, the user’s current location or the current time can cause the user to be added to or removed from a certain role.
When Should You Use RBAC vs. ABAC?
The best access control model to use depends on your company size and organizational structure. The following table summarizes possible use cases.
|Organizational Structure||Appropriate Access Model||Example|
|Small teams||RBAC||In a small service company with 20-30 employees organized into small teams, RBAC is easy to set up and appropriate for security needs.|
|Geographically distributed teams||ABAC||A field service organization with teams in different locations may need different access for each team depending on location and time. ABAC can provide this capability.|
|Temporary workgroups||ABAC||A project management company forming groups for specific projects needs to grant access to materials relevant to the project, only during the project duration. ABAC is more appropriate to time-sensitive permissions.|
|Review cycles||ABAC||An editorial organization may need to perform reviews on some documents involving multiple team members, share other documents with all team members, and secure specific documents. Because permissions are assigned by document and not by role, ABAC is more appropriate.|
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.
NGAC and the NIST Policy Machine: The Hybrid Approach
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:
- RBAC can suffer from role explosion, and can become unmanageable at large scale.
- ABAC enables complex access logic, but when access rules are complex, authorization processing times can become very high.
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.
How does NGAC work?
NGAC uses several types of entities that represent protected resources and the actors that need to access them:
- User attributes
- Objects (such as folders)
- Object attributes
- Policy classes (for example, location or time)
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.