Setting permissions isn’t “just tick who can see it.” The question “can he see this?” has three different forms — by role, by condition, by relationship — and each form needs a different mechanism.
Three questions, three models
| Model | The question | In one line |
|---|---|---|
| RBAC (by role) | Which badge do you wear? | One role for a group; change once, everyone follows |
| ABAC (by condition) | Are the conditions met right now? | Department / time / environment, evaluated per request |
| ReBAC (by relationship) | Are you connected to this record? | Relationships chain; “who owns this row” is answered by edges |
Standards/practice: NIST RBAC (INCITS 359), NIST SP 800-162 (ABAC), Google Zanzibar (ReBAC).
Every model has a cost
- By role: roles balloon as the org grows.
- By condition: policies get complex, hard to read, slower to evaluate.
- By relationship: edges chain and a change can ripple widely — one large-scale system stores 2+ trillion relationship tuples and serves millions of requests per second (Zanzibar).
How to choose
- Managing a class of people → RBAC.
- Managing a pile of conditions → ABAC.
- Managing who owns this record → ReBAC.
In practice you mix them — it’s not a choice of one. And one baseline always applies: grant least privilege by default (NIST SP 800-53 AC-6) — a new account starts with only what it needs.
These practices come from building Autional, an open-core identity layer — https://www.autional.com
Reference: ANSI/INCITS 359 (NIST RBAC), NIST SP 800-162 (ABAC, 2014), Google Zanzibar (USENIX ATC 2019), NIST SP 800-53 AC-6.
Top comments (0)