🪄 Migrating from RBAC to ABAC with Permit.io 🐕🤯

RBAC VS ABAC

Role-based access control (RBAC) has been a popular authorization approach for decades. After a user logs in to the system (is Authenticated), RBAC allows assigning permissions to application-level roles, which in turn provide or deny access to certain areas of an application.

However, RBAC has limitations and is often insufficient for modern applications with complex authorization requirements.

This is where Attribute-based access control (ABAC) comes in.

ABAC is a more granular method of managing permissions. Instead of relying solely on predefined roles, it allows considering various attributes to make access decisions. These attributes can include user data, location, time, and many more. While ABAC provides a more flexible and fine-grained approach to authorization, it can be really complex to set up and manage - making the migration process from RBAC to ABAC extremely challenging for developers.

When is RBAC not enough?

Let's consider a practical example. Imagine a fintech application that allows users to invest in various financial products, such as stocks, bonds, and funds. Initially, the application uses a traditional RBAC approach to manage authorization, with roles such as "basic user," "premium user," and "administrator."

Over time, the application evolves, and the variety of services it provides increases. It now needs to provide access based on attributes such as:

1. Time of day: Certain financial products may only be available for investment during specific times of the day, such as when certain markets are open.

2. Investment type: Users may only be authorized to invest in certain types of financial products based on their risk profile, investment objectives, and other factors.

3. Investment amount: Depending on the user's investment history, they may be authorized to invest higher or lower amounts in certain financial products.

4. Location: Certain financial products may only be available for investment in certain geographic locations, depending on local regulations and laws.

In a Fin-Tech application, we can have more application-specific attributes like ”Portfolio diversity, which authorizes users to invest in a certain number of different financial products to ensure portfolio diversity, or Investment experience, which allows users with more investment experience may be authorized to invest in more complex financial products with higher risks.

Each application may have application specific authorization rules that depend on the context of what the application allows its users to do.

An RBAC system won’t be able to support managing permissions for any of these services (Let alone all of them) ABAC, on the other hand, provides a more granular approach, being able to handle much more complex authorization policies, allowing your application to offer a much wider variety of services.

You can learn more about the decision between RBAC and ABAC here.

The journey from RBAC to ABAC

Based on dozens of conversations with other developers who went through this exact scenario building their own application, the journey from homebrew RBAC to ABAC is usually described somewhere along the lines of ‘terrible, time-consuming, meticulous, frustrating, and generally extremely unpleasant’.

The migration from a homebrew RBAC solution to ABAC can take from a few weeks to several months of RnD work , and often includes a complete overhaul of the existing RBAC-based permission management system.

The process of migrating from homebrew RBAC to ABAC involves several steps:

First, you need to analyze the existing RBAC system and identify its limitations and areas for improvement. Next, you need to define the attributes for the new ABAC system, such as user data, location, and time.

Then, the new ABAC system must be designed and implemented, ensuring full integration with the application. Finally, the system needs to be tested thoroughly to ensure it functions correctly and meets the organization's security and compliance requirements. This entire journey will require you to devote the entirety of your time to building your new authorization layer instead of developing the core unique features of the application.

A key problem that devs face here is performance : The data for ABAC queries often requires different database schemas, and expecting the application's default db schema to work efficiently for ABAC out of the box usually leads to db performance issues and application downtime.

The story doesn’t end there either -

Once you have ABAC set up, creating additional roles, attributes, and policies requires ongoing, complex R&D work. This creates a situation where developers become bottlenecks in your app’s permission management , and other stakeholders are locked out of the conversation.

Not to mention the fact that as various requirements from customers, security, compliance, and 3rd party integrations come in, you might need to refactor your entire authorization system every 3-6 months.

From RBAC to ABAC with Permit

Permit makes the transition from RBAC to ABAC much easier by offering a simple no-code permissions management UI. Providing full stack authorization as a service, Permit allies you to define policies based on user attributes and context without needing to write any custom code or make significant changes to the application's architecture.

Permit provides a permission management solution that makes policy-as-code as easy as checking a checkbox - generating the needed code for you, and wrapping it nicely into Git, and API / UI interfaces.

This allows for both easy implementation and management of RBAC and ABAC, and a seamless transition between the two - all without writing a single line of code.

Learn how to setup ABAC policies with Permit’s UI here

Permit’s No-Code ABAC UI

While RBAC has been a reliable authorization approach for many years, it is often insufficient for modern applications with complex authorization requirements. ABAC provides a more flexible and granular approach that can adapt to an organization's changing needs. However, migrating from RBAC to ABAC can be a challenging process. With the help of tools like Permit, you can make the transition much more manageable and enjoy the benefits of ABAC.

Want to learn more about Authorization? Join our Slack community, where there are hundreds of devs building and implementing authorization.