Roles and permissions are 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 with? 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, yet traditional approaches we tend to find on SaaS applications.
So how does the RBAC model actually look?
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, 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:
So 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.
The aforementioned approach 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..
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” while 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 or time of day?
Let’s try to challenge the RBAC model:
Let’s assume that we want the users to be able to deploy versions only if they are part of the C-Level approved list in our organization? 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).
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.
All 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? Who wins the RBAC vs ABAC technological tussle?
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, RBAC will be easier 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 dramatically improve the performance of the engine. Additionally, 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 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 is no clear winner in this technological battle because each methodology has its own inherited benefits. With user behaviour 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.