Roles and permissions is a mandatory part of every application, especially when approaching larger customers with complex authorization needs. The ability to control which user can do what, is an essential part of any B2B application, especially when approaching those enterprise deals that require granular control.
The AuthZ part is usually the second layer we choose to handle in our SaaS application. The first concern will usually be the Authentication of the users and being able to log them in securely. 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? Should we base our authorization on roles, organization units or locations?
All of the above are legit questions and concerns that each SaaS application owner faces at some stage of the application lifecycle.
This post is a review of the differences between the traditional RBAC and the more modern ABAC in order for us to be able to choose the correct tool and method when providing AuthZ out of the box.
RBAC (Role Based Access Control)
RBAC is one of the most common and yet traditional approaches we tend to find on SaaS applications.
This concept is pretty straight forward. 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 your users? As you can imagine, each 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:
So the combination of having a user that belongs to several roles and the combination of permissions which can also belong to several roles, leads to a flexible model that is oftentimes hard to manage.
The approach above is one of the more standard approaches for RBAC based authorization but you’ll often find that along the way, when approaching more sophisticated customers, you are presented with additional service requests. These often include:
Granular RBAC — Delivering an application with 2-3 basic roles and permissions will do in most cases. However, when approaching more complex companies you will face demands for setting up additional “custom” roles based on the customer we are approaching.
For example, we can deliver our application with “Admin”, “Maintainer” and “Operator” roles while the customer can create 2 additional roles of “read-only” and “support” and setting up additional permissions for it.
In these cases, our APIs will need to be protected based on permissions and not roles as the 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 usually won’t allow this permission to be accessed by a lower level within the hierarchy.
So RBAC can be simple on one hand and extremely complex on the other hand. And it makes sense. But is it enough? How do we support grouping of users based on other properties they present such as Location / security level / time of day?
Let’s try to challenge the RBAC model:
Let’s assume that in our organization we want the users to be able to deploy versions only if they are part of the C-Level approved list? How do we prevent users from deploying a version in the middle of the night? How do we ensure that they can approve a PR only when they are connected via VPN?
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).
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.
All of the attributes are being processed by an “Authorization engine” which evaluates and allows / denies the operation being discussed. The architecture will look like this (in most cases):
Let’s challenge the ABAC model by providing a use-case which we couldn’t solve with RBAC: “Provide John (user attributes) with access to the company’s repository (resource attributes) only when connected via VPN (environment attributes).
Limiting a user’s access to specific resources from a specific location while striving for greater flexibility and the ability to control resources on a granular level is not a use case we were able to achieve within the basic RBAC.
So that sounds nice, but can we replace RBAC use cases with ABAC?
Let’s challenge that as well: “Provide access to users with “Admin Role” (user attributes) to the company’s repository (resource attributes).
So now we can handle Role Based filters with ABAC!
Great! Should we switch?
Generally speaking, in most of these cases, your application will live long using RBAC alone so you probably should make use of it before setting up ABAC access control.
As we saw before, RBAC can be accomplished with the use of ABAC (with filters on the user attributes), however ABAC requires more processing power and is much more complex to handle, implement and maintain.
As in most cases with SW development and product development, you should plan ahead. If your product is a super technological one and aims at nailing big enterprise deals with heavy granular security concerns, ABAC is the way to go. If the product is more suited to SMBs or companies without heavy security concerns then RBAC will be simple to integrate.
EBAC as the hybrid approach?
Due to the complexity of the ABAC model, and the “over simplification” of the RBAC model there is a need to build hierarchies between RBAC and ABAC models. This approach is called EBAC (Entity Based Access Control)
EBAC is a simple subset of ABAC and doesn’t bring to the table any new concepts rather than a simplified model of ABAC.
Under the EBAC model, we will first use the RBAC engine in order to quickly determine the user’s first access layer and then we will operate the ABAC model in order to evaluate the requested entity.
While the implementation of both models seems like too much to handle, the hybridification of both RBAC and ABAC will improve dramatically the performance of the engine.In addition, for most use cases the environment variables and filters for ABAC will better suit the “Firewall” use cases whereas the resource variable for ABAC will better suit SaaS applications with clustering of resources based on groups (for example, 10 repositories connected to the same tenant with different permissions based on the user attributes)
The world of handling permission 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.
As we have seen with 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)
At Frontegg we took all of these into consideration when building our SaaS as a Service platform. 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.