RBAC vs ABAC Authorization Model

Authentication and authorization play a crucial role in preventing security breaches or unauthorized access to either the whole application or certain restricted resource of our application. Authentication checks if the user that is trying to access the application is a valid user or not while authorization controls what the user can access within the application typically a restricted resource.

While the main goal of both authentication and authorization is to maintain overall security of our application, in this blog we are only going to discuss about authorization and its different models. The described models have their own use case and choosing between them can be a tricky as it heavily depends on how much fine grained control we want in our application.

Here we are taking an example of a restaurant and for this example we are using Express for developing routes so that clients can interact with server, PostgreSQL for database as well as Typescript for type safety. You can still apply all the described models using any language, framework or database as the core concepts are same.

RBAC (Role Based Access Control)

Role based access control can be defined as the authorization model in which a user is assigned with a static role which determines the level of access control that they get within the application. Typically a restaurant has an owner and number of different staffs associated with it. Here the owner can create, read, update and delete the menu items where as the staffs can only read the menu items.

A typical database table for RBAC looks like this where we have a separate column that specifies respective roles to the users:

Users table:

Menu items table

Code

This code uses typescript to define the request body structure but if you are not using typescript then please skip that part. Also this code only shows the permission check while creating a menu item.

Code explanation:

• We are getting the user_id, name and price of the item that we are going to create from request body.
• Then we are querying our database to get the user so that we can differentiate between the roles of user who can create the menu item.
• We then are checking that the user that is trying to create the menu item has the role of Owner or not and if they don't then we are returning respective response whereas if they do have the role then we are letting them create a new menu item and returning respective response.

As simple as this authorization model looks, it falls apart when we want more fine grained control on who can access what and to which level.

Attribute Based Access Control (ABAC)

Attribute based access control can be defined as the authorization model in which a user is assigned respective permissions based on the attributes that they have. For example: A staff member who is a manager can only perform certain actions. While the RBAC works fine for application with simple authorization mechanism, ABAC comes into play when our application needs fine grained control. For example: What if we want to only allow the staff who is manager to be able create, update, read the menu items but cannot delete the menu items or can read sales details unlike normal staff members. This is where this authorization model comes into play.

For simplicity, we can define a table called policies where authorization policy for each user can be stored along with their id. The table can look like:

Policies table

Here the column action defines the action that the user can perform in the application where as the column object is the resource that the user can perform the action to. Also the other column group defines the domain that the user lies in.

Code

Code explanation

• In the above code first we are getting the user associated with the user id so that we can get the role of the user which will be used for further authorization checks.
• Similarly we are querying the policy table to get all the actions that the user has within the specific group (in this case staff) where they can perform action to the passed object (in this case menu item).
• Then we are checking if the user's role is manager and the action that has been passed via query is included in the allowedActions array or not. If the passed action is not available we send a response indicating that the user doesn't have necessary permission to perform the action else we send happy response to the user.

The policies table schema is designed in such a way that even if the role of user is Manager, if the domain/group of the user (from policies table) is not staff they cannot perform the respective operations. This makes the authorization more robust and dynamic as compared to RBAC.

Conclusion

Even if the above explained examples are not production ready they provide a base knowledge on how these authorization models work along with their use case and how they can be combined together to build a robust authorization model in our application. Along with these two authorization models, we have another authorization model known as Relationship Based Access Control (ReBAC) that defines the access to resources based on graph of relationships which you can explore if you want to dive more into authorization models.

If you have any queries or if the examples shown in the blog are incorrect then please let me know in the comments.

Github: https://github.com/sandesh2811/authorization-models

Thank you for reading!