RBAC
Role-Based Access Control: permissions are assigned to roles, users get roles. Scales authorization far better than per-user ACLs. The most common authz model; ABAC adds attribute-based rules for finer control.
- Most apps with distinct user types.
- Manageable, auditable authorization.
- Highly dynamic, attribute-driven policies (use ABAC).
- Tiny apps with one user type.
Definition
RBAC maps users to roles and roles to permissions. A user in the 'editor' role can do editor actions. Roles group permissions, so adding a user is a role assignment, not a per-permission grant. Hierarchies and policies extend it.
Why it exists
Per-user permissions don't scale: thousands of users × resources is unmanageable. Roles group common permission sets, making authorization manageable and auditable.
How it works
Define roles and their permissions. Assign users to roles. On a request, check the user's roles' permissions against the required action/resource. Often enforced at a gateway or middleware. ABAC adds attributes (time, IP) for dynamic rules.
Scaling limits
Role explosion: too many fine-grained roles become unmanageable. Cross-cutting rules need ABAC. RBAC is coarse for complex policies (e.g. 'only your own data' needs ownership checks too).
Cost shape
Cheap (role lookups). Cost is the administrative burden of role design and review.
Alternatives
- ABAC — Fine-grained attribute rules, more complex to manage.
- ACLs per user — Fine-grained but doesn't scale.
Failure modes
- Role explosion.
- Over-permissive roles.
- Stale role assignments.