RBAC
One evaluator both runtimes share, routes that cannot be unguarded by accident, and reference data without a permission.
Overview
This document covers why the permission rather than the role is the unit of authorisation, keeping one evaluator so the client and server cannot disagree, the semantics that must fail closed, proving every route is guarded rather than trusting review, and the reference-data problem that otherwise forces unrelated permissions on everyone.
Why This Exists
Authorisation defects are quiet. Nothing throws, no log line appears; a list simply contains a row it should not, or an action succeeds that should have been refused. They are found by someone noticing, which is not a detection strategy. So the useful work is structural: make the unguarded state impossible to express rather than discouraged, make the client and server incapable of disagreeing, and make the dangerous default the one that cannot be written.
The permission is the unit; roles are bundles
One evaluator, shared by both runtimes
Semantics that must fail closed
Prove every route is guarded
The reference-data problem
Synchronising definitions with what is granted
Related Principles· 3
Related Documents· 3
Related Case Studies
Referenced By· 2
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience. Covers permissions as the unit, one shared evaluator, the fail-closed semantics including the empty-requirement defect found through a consumer's workaround, deriving the route posture test rather than maintaining it, the reference-data endpoint, and reconciliation with its production risk.