Access Models

"Can Alice edit this document?" There are three good answers and they are not the same answer. Because she is an editor (a role she holds). Because the document is in her department and it is not yet locked (attributes of her, of it, and of the moment). Because she is the owner, or someone who owns it shared it with her (a relationship between the two). Each of those is a legitimate authorization model, each is a different piece of code, and picking one by accident — one if statement at a time, as features arrive — is how permission logic becomes something nobody can reason about a year later.

The track works through all three deliberately. RBAC groups permissions into roles, which is easy to explain and audit and tends over time towards role explosion, as every combination of exceptions earns its own near-duplicate role. ABAC decides from attributes of subject, resource and context, which is far more expressive and correspondingly harder to answer "who can reach this?" about. ReBAC decides from relationships in a graph — owner, member, shared-with — which is what consumer products almost always mean by sharing, and what makes "everyone in the folder's team" a natural rule rather than a special case. You will express the same decision in each and see what each makes easy and what each makes awkward.

Underneath all three sits a default, and it is the most consequential line in any policy: when no rule matches, what happens? Deny by default means a forgotten rule denies access, which produces a support ticket. Allow by default means a forgotten rule grants it, which produces an incident. The track closes on the confused deputy — a privileged component performing an action for a caller who could not have performed it directly, because it checked that it was allowed rather than that the caller was. It is the shape behind a surprising share of real access-control bugs, and in P59 it returns wearing an agent costume.