Is RBAC Still Relevant? Am I?
Is RBAC dead? Will copilot replace all developers and take all of our jobs? Let’s find out -
Hello there! Daniel here with another digest 💌
This time, we pose you a question - Is RBAC dead?
The answer to this, and also to my favorite clickbait article question: “Will copilot replace all developers and take all of our jobs?” is -
You've probably heard of Role-Based Access Control (RBAC). It’s so common that developers casually describe their authorization service as an “RBAC service,” and CTOs describe it as “The thing we’ll implement at some point.”
RBAC is great and all, but if you’re subscribed to this newsletter, you probably know by now that there are more options for app-level authorization. Models such as Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC) are gaining more and more attention, overshadowing the once-beloved and well-known RBAC.
There’s a good reason for that — applications have grown increasingly complex in recent years, and RBAC can’t really handle things that seem like very basic requirements from basically any app we use today (more on that soon). This, again, makes me (and hopefully you) wonder - ****
Is RBAC Still Relevant?
Here’s a question that constantly pops up in our Slack Community -
“Should we consider RBAC, or should we migrate to one of the new cool authorization models?” (That’s you, our community members. That’s what you sound like).
The answer to it, in short, is: Well, yes. It’s more relevant than ever.
Why? Well, before we tell you that, let’s first see how RBAC became the big deal it is today.
How did RBAC become such a big deal?
If you have ever messed around with software security, you probably know the biggest vulnerability application security features have stems from a lack of experience - both on the user and developer sides. Any security feature that provides bad UX / DevEx will most likely be skipped by both, resulting in an even worse vulnerability than before. There’s nothing worse than implementing a security feature and thinking you solved the problem only for nobody to ever use it.
That’s exactly the trouble RBAC avoids- it provides a great experience for both developers and the application’s end users.
For the developer, RBAC decouples the relationship between users and the permissions they need. Instead of explicitly assigning permissions to a user and applying that across different resources in the system, we assign permissions to roles and roles to users. That means that when we want to add more permissions, we can add them to a role instead of manually adding them to individual users.
For the user, RBAC makes app permissions easy to understand, with users not having to focus on how the app is built but rather on their own roles. Knowing if you are a standard user or an admin is a much more straightforward way of understanding the permissions you have within the app, unlike ACL and other, older models, that were common before RBAC’s growth in popularity.
So when isn’t RBAC enough?
You might ask yourself then - “if RBAC is so great, why ever replace it?” Well, as simple as RBAC might be, that simplicity comes with a price. In cases where a more fine-grained approach is needed, it just doesn’t cut it these days. The user-centric approach of RBAC makes the user the only dynamic component in the policy. That’s an issue. If we want to get more dynamic and granular policies, like, for example, where certain attributes of resources constantly change, RBAC proves insufficient. That’s true for many modern applications, considering their complexity and the amount of data they rely on.
It’s interesting to see that what brought RBAC to fame is the same thing that is now promoting the use of other models—user requirements. Users both have a better understanding of software, and they expect more control over their permissions than ever before. Things like privacy, data, and ownership are becoming very basic requirements that RBAC can no longer satisfy.
In the defense of Role Based Access Control
Now that we’ve dragged it through the mud, it’s time to ask when RBAC is still relevant.
TL;DR - as a baseline for Policy as Code and Policy as Graph systems.
Two prominent models have emerged in the past few years, threatening RBAC’s dominance of the authorization space. We mentioned these before: Relationship-Based Access Control (ReBAC) and Attribute-Based Access Control (ABAC). Want a quick overview of the differences between all three? We’ve got your back.
ReBAC extends on basic RBAC by considering the in-app relationship between objects, users, and roles. If you look at something like a ‘Google Drive’ style authorization system, you’ll quickly notice that it uses the baseline of roles, actions, and resources you already know from RBAC and extends upon them with relationships. The same goes for ABAC—it uses RBAC as a baseline structure and extends it by adding attributes to existing RBAC elements.
This demo healthcare app we made is a good example of how all three can be combined.
The simplicity of RBAC makes it a great baseline for modeling your authorization system, while other models, such as ABAC and ReBAC, are layered on top to cater to more granular requirements. In Permit, we use RBAC as a baseline for our no-code policy editor and allow our users to layer ABAC and ReBAC on top of it - most of our users end up using a combination of all three models.
As long as you implement RBAC while following the best practices for it, it will help you cover the basics of your authorization requirements and allow you to extend it using other models if the need arises. In short, because the nature of policy as code or policy as graph systems separate configuration and data, it becomes quite easy to scale from RBAC to more complex models, as you can see in this guide about scaling with AWS’ Cedar engine.
RBAC is also great for streamlining your fine-grained authorization with feature-toggling that manages the visibility of resources in your frontend apps. The frontend authorization layer usually benefits from RBAC’s simplified abstraction and simplicity. We wrote two pieces about this recently, one from the frontend perspective of the React framework, and another from the full-stack perspective in Next.js.
So, is RBAC still relevant? Of course it is, maybe more than ever, because every complex architecture should have a simple baseline. Oh, and you need to know how code works to be able to know when copilot is doing this:
Wow, this one came out long. As always, it’s been a pleasure. If you’ve read this far, join the rest of us authorization nerds in our Slack Community!