RBAC

The Corporate Badge System

Imagine working in a massive corporate headquarters. On your first day, security hands you a plastic badge on a lanyard.

If you are an intern, swiping your badge gets you through the front door, into the main work areas, and into the cafeteria. If you walk up to the server room door and swipe, the light flashes red, and the door stays locked.

However, if the Chief Technology Officer (CTO) walks up to that exact same server room door and swipe their badge, the light turns green, and the door opens.

The security system doesn't have a giant list of 5,000 employees with individual yes/no toggles for every single door in the building. That would be impossible to manage. Instead, the system assigns people to Roles (Intern, Engineer, CTO), and then assigns permissions to those Roles.

This is exactly how RBAC (Role-Based Access Control) works in software systems.

The Nightmare of Direct Permissions

To understand why RBAC is so brilliant, we have to look at the alternative: direct permissions (sometimes called Discretionary Access Control).

Let's say you are building a tool for a hospital. You have resources like "Patient Records", "Billing Data", and "Staff Schedules".

If you use direct permissions, you must attach permissions directly to the user account:

• Dr. Smith: Can Read Records, Can Write Records.
• Nurse Joy: Can Read Records.
• Accountant Bob: Can Read Billing.

This works fine when you have 10 employees. But what happens when the hospital has 5,000 employees? Every time a new nurse is hired, an IT admin has to manually click 50 different checkboxes to give them the right permissions. If a nurse transfers to the billing department, the admin has to manually uncheck 50 boxes and check 30 new ones.

Inevitably, humans make mistakes. Someone gets the wrong permissions, and suddenly a temporary intern has the ability to delete patient databases.

Enter RBAC

RBAC introduces a middle layer between Users and Permissions. That middle layer is the Role.

Instead of assigning permissions to users, you assign permissions to roles. Then, you assign users to roles.

1. Permissions:
   • read:records
   • write:records
   • read:billing
   • delete:billing
2. Roles:
   • Doctor Role: Contains read:records and write:records.
   • Accountant Role: Contains read:billing and delete:billing.
3. Users:
   • Dr. Smith is assigned the "Doctor Role".
   • Bob is assigned the "Accountant Role".

Why this scales beautifully

When a massive group of 50 new doctors joins the hospital, the IT admin simply assigns them all the "Doctor Role." One click. If the hospital administrators decide that doctors should suddenly have the ability to view billing data, the IT admin just adds the read:billing permission to the "Doctor Role." Instantly, all 500 doctors in the hospital inherit the new permission.

It is clean, auditable, and vastly reduces human error.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

RBAC in action: users are assigned roles, and roles carry a defined set of permissions. Alice has the Engineer role and can access logs. Bob has the Viewer role and cannot. When Alice changes departments, swapping her role is one operation that removes all Engineer permissions and grants the new role's permissions simultaneously.

1 / 10.5×1×2×3×Playground

RBAC: users are assigned roles, roles carry permissions, and the API grants or denies requests based on the role

Principle of Least Privilege

RBAC enables one of the most important concepts in system security: The Principle of Least Privilege.

This principle states that a user, program, or process should have only the bare minimum permissions necessary to perform its specific job. Nothing more.

If a marketing employee only needs to view reports, you give them a "Viewer" role. You absolutely do not give them an "Admin" role just because it's easier to set up. If that marketing employee's account gets hacked via a phishing email, the hacker is constrained by the "Viewer" role. If they had an "Admin" role, the hacker could destroy the entire company.

Beyond Humans: Service Roles

RBAC isn't just for human beings. In modern cloud architecture, services need permissions to talk to other services.

For example, your web application running on a virtual machine might need to read photos from an AWS S3 bucket. You don't hardcode a password; instead, you assign an IAM Role (Identity and Access Management) to the virtual machine itself. The role explicitly states: "Can read from the Photos bucket, but cannot delete anything."

Summary

• Direct permissions (assigning rights directly to users) does not scale and leads to massive security risks via human error.
• RBAC (Role-Based Access Control) introduces Roles as a middle layer. Permissions are assigned to Roles, and Users are assigned to Roles.
• RBAC allows for massive scalability and easy auditing. When a person changes jobs, you just swap their role.
• The Principle of Least Privilege dictates that roles should be as restrictive as possible, granting only the access necessary to complete a job.
• Cloud platforms use RBAC extensively not just for humans, but for computer services talking to other computer services.