CodeParkUse RBAC for simple, coarse access. Use ABAC for fine-grained rules based on context. Use ReBAC for sharing and nested ownership.
RBAC (Role-Based Access Control) gives permissions to roles, and roles to users. For example, the editor role has the publish:article permission. It's easy to understand and easy to audit (check who can do what). But it can't express rules about one specific object, or rules that depend on context, unless you create many roles.
ABAC (Attribute-Based Access Control) decides from attributes, which are facts about the request. These attributes describe:
- the subject (the user), such as their department
- the resource, such as who owns it or its data classification
- the action
- the environment, such as the time of day
ABAC is expressive and fine-grained. But it's harder to test and harder to explain.
ReBAC (Relationship-Based Access Control) decides access from relationships. For example: "the user is a member of a team that owns this folder". Google's Zanzibar paper made it popular. It suits document sharing and nested multi-tenant hierarchies (for example, company, then team, then folder).
Real systems often combine them. They use roles for coarse access to features, plus ownership or relationship checks for single objects. Whatever the model, follow three rules:
- enforce it on the server
- keep it in one central place
- deny by default (refuse access unless a rule allows it)
- RBAC maps roles to permissions. It is simple but coarse.
- ABAC uses policies over attributes. It is fine-grained but harder to audit.
- ReBAC uses a graph of relationships. It is good for sharing.
- Real systems often combine these models.
- Keep access control central, on the server, and deny by default.