Beyond Basic Access Control: Understanding RBAC, ABAC, and ReBAC - A Guide to Modern Permission Systems
December 3, 2024
Access control is one of those things that sounds simple but gets complicated fast. At its core, it's about answering two questions: "Are you who you say you are?" and "What are you allowed to do?" Let's break down the main approaches companies use to solve this puzzle.
Think about your company's file system. The CEO can see everything, while a new junior engineer has limited access. As one of Databricks' founders noted, they built their entire system with enterprise needs in mind from day one. They spent enormous time getting governance right, including access control, because without it, no serious business would touch their product.
So how do you build this? Let's look at the evolution of access control systems, from simple to sophisticated.
Access Control Lists (ACL)
The most straightforward approach is like a guest list at an exclusive club. You maintain lists of who can do what. Want to read a document? We check if you're on the list.
Some systems even let users share their access rights with others (called Discretionary Access Control or DAC). It's like being able to bring a plus-one to that exclusive club.
But there's a catch.
ACL works great for small teams. But imagine a company with 1,000 employees. Every time you create a new document type or system feature, you need to update lists for hundreds of people. It quickly becomes a management nightmare.
Role-Based Access Control (RBAC)
This is where RBAC (Role-Based Access Control) comes in. Instead of managing individual permissions, you create roles - like "Engineer," "Manager," or "HR Staff."
Think of it like hotel key cards. Rather than programming each key individually, you create different types of keys (roles) with specific access levels, then give people the appropriate type.
Major systems like MongoDB and Jira use RBAC because it scales well. Need to give all engineers access to a new tool? Just update the "Engineer" role once, and everyone with that role automatically gets access.
The RBAC Problem
Role-Based Access Control (RBAC) works well... until it doesn't. Here's a real scenario: Your company decides engineering interns shouldn't edit technical documents, even though all other engineers can.
With RBAC, you'd need to create separate roles for interns, junior engineers, senior engineers, and CTOs. Suddenly, your "simple" role system isn't so simple anymore. It's like having to create different types of employee badges for every tiny variation in access privileges. It gets messy fast.
Attribute-Based Access Control (ABAC)
Attribute-Based Access Control (ABAC) is like a smart doorman who checks multiple factors before letting someone in. Instead of just looking at roles, it considers:
- Who you are (position, seniority)
- When you're trying to access (time, date)
- What you're trying to access (document type, security level)
- Where you're accessing from (location, network)
Think of building access: "Senior engineers from Team A can enter Building B on weekdays between 8 AM and 8 PM." That's ABAC in action. Major cloud providers like AWS and Azure use ABAC because it's flexible. Need to restrict access to confidential documents? With ABAC, you just add one rule. No need to reorganize roles or update lists.
But ABAC has trade-offs:
- It's harder to quickly see who has what access
- Checking multiple attributes takes more computing power
Relationship-Based Access Control (ReBAC)
Relationship-Based Access Control (ReBAC) thinks about permissions like a family tree. Google's systems (Drive, Calendar, YouTube) use this model through their Zanzibar system.
In Google Drive, if you have access to a folder, you automatically have access to everything inside it. It's like giving someone a key to a house - they can also open all the rooms inside. Many modern systems combine RBAC with ReBAC. It's like having both job titles (roles) and organizational relationships determine what people can access.
ReBAC's challenges?
- Calculating relationships requires computing power
- It's not as flexible as ABAC for complex rules
The key insight here is that there's no perfect system. Each model solves specific problems while creating others. Smart organizations often mix and match these approaches based on their needs.
Why Permissions Matter More in B2B
Consumer apps (B2C) usually keep permissions simple. But in business software (B2B), permissions become a different beast entirely. Why? Because businesses have complex hierarchies, departments, and roles - each needing precise access controls.
When B2B systems get permissions wrong, chaos follows. Engineers get emergency calls because sales teams can't access what they need (or worse, can access what they shouldn't). Instead of building new features, teams spend hours debugging permission issues.
Let's look at how to avoid these headaches.
Three Key Principles for Permission Design
1. Choose the Right Tool for the Job
Just because ABAC is more flexible than RBAC, or RBAC scales better than ACL, doesn't mean you should always choose the more "advanced" option. It's like choosing between a Swiss Army knife and a regular knife - sometimes simpler is better.
- For a small, simple system? ACL might be perfect
- Managing enterprise roles? RBAC could be your sweet spot
- Need complex, dynamic rules? Then consider ABAC
Remember: The simplest solution that solves your problem is usually the best one.
2. Keep Permission Logic Loosely Coupled
Think of permission rules like LEGO blocks. You should be able to add or remove them without breaking everything else. If changing one permission requires updating ten others, that's a red flag.
Good permission design means new rules can be added without touching existing ones. If you find yourself constantly modifying old permission logic, it's time to refactor.
3. Test, Test, Test
Here's a war story from Figma: When they needed to overhaul their permissions system, they faced a crucial question - how to ensure nothing breaks? Their answer: comprehensive automated testing.
They integrated permission tests into their CI/CD pipeline and spent weeks ensuring every test passed before migrating. It's like having a safety net when walking a tightrope - you really want it there.
The Bottom Line
There's no one-size-fits-all solution for permissions. Many successful companies use multiple systems - RBAC for some products, ABAC for others. The key is matching the right model to each specific need.
Think of it like security in a physical building. Some areas might need just a key card (simple ACL), others need both a key card and biometric scan (RBAC), and some might need additional time-based restrictions (ABAC).
It's about using the right level of security for each situation.The best permission system isn't necessarily the most sophisticated - it's the one that solves your specific problems while remaining maintainable and scalable.