Role-Based Access Control (RBAC)
A method of restricting network access based on the roles of individual users within an enterprise.
Detailed Explanation
In RBAC, permissions are assigned to roles (e.g., 'Admin', 'Editor', 'Viewer'), and users are assigned to those roles. This simplifies management because you don't have to assign permissions to every user individually. As a user's job changes, you simply change their role. It is the most common model for internal business applications.
Quick Summary
RBAC groups permissions into roles and assigns roles to users. It scales authorization management linearly with roles rather than combinatorially with users × permissions.
Key Takeaways
- Three levels: users → roles → permissions. Permissions are never granted to users directly.
- Common roles cluster by job function: admin, editor, viewer, billing, support.
- Role explosion is the main failure mode, when business reality needs `admin-except-billing`, you grow roles forever.
- Combine with ABAC (Attribute-Based) for conditions roles can't express, like "only their own records."
- Audit and review role assignments quarterly; offboarding rarely catches every permission orphan.
When to use it
- SaaS apps with Owner / Admin / Member / Viewer tiers.
- Cloud IAM (AWS, GCP, Azure), roles bundle hundreds of API permissions.
- CMSes where editors publish, contributors draft, and viewers read.
- Internal tools where engineers, finance, and support need disjoint slices of customer data.
Common Mistakes
- Granting permissions directly to users "just this once", bypasses the entire model.
- One mega-role (`super-admin`) that everyone gets because it's easier than designing properly.
- No periodic review, roles accumulate permissions over years until even "viewer" can do real damage.
- Mixing role definitions across services without a single source of truth, drift is inevitable.
Role-Based Access Control (RBAC), Frequently Asked
RBAC vs. ABAC?
RBAC answers "what role is this user in?" ABAC answers "do this user's attributes match this resource's attributes?" Use RBAC for coarse grouping (admin/editor) and ABAC when decisions depend on the resource (only the document's owner can edit).
How granular should roles be?
Coarse enough that a non-engineer can reason about them, fine enough that least privilege is achievable. Five to fifteen roles is healthy; fifty roles usually means your model needs ABAC or scopes instead.