RBAC, Default Deny and Least Privilege

A role name is not an authorization proof. A user can be authenticated, the interface can hide an action, and a server can still make the wrong decision if the policy at the protected boundary is incomplete. This lesson builds one bounded, inspectable authorization model and tests it only in a synthetic local fixture.

1. The problem before the role names

The scenario is a synthetic project workspace. It has three roles: Viewer, Editor, and WorkspaceAdmin. Resources belong to a workspace. Protected actions include reading projects, reading or writing files, and managing workspace members. The security question is not “what can an Editor usually do?” The question is: may this subject perform this action on this resource in this context?

2. Bounded outcome

You will produce Authorization Decision Matrix v1. Each decisive row must identify a subject or role, resource scope, action, explicit allow rule, default decision, enforcement point, positive probe, negative probe, observed evidence, and any residual policy question.

3. What this lesson does not prove

The local fixture does not prove a production system is secure. Authentication success does not imply authorization. UI visibility is not an authorization control. RBAC is not assumed to be the best model for every policy. A single all-powerful administrator role is not treated as a convenience shortcut.

4. Authorization as a decision tuple

Think of an authorization request as a tuple: (subject, action, resource, context). A role is one input to the decision. Resource ownership or workspace scope can be another. The decision must be made against an explicit policy at an authoritative enforcement point.

5. Subjects and roles

A subject is the concrete caller. A role groups permissions that belong to a task. In the fixture, Viewer can inspect workspace content, Editor can also modify files, and WorkspaceAdmin can manage members. The role does not erase subject-specific context such as workspace membership.

6. Resources and actions

A permission is meaningful only when attached to an action and a protected resource class. file.read and file.write are different actions. member.manage is a different privilege domain. Combining them under a vague “edit” permission makes least-privilege review harder.

7. Explicit allow rules

An allow rule should be inspectable. The local evaluator uses an explicit role-to-permission map plus a workspace-scope check. If an allow condition is not represented, the learner should not infer it from navigation, naming, or a successful login.

8. Default Deny

When no explicit allow rule matches, the decision is deny. This makes new or forgotten actions fail closed in the bounded policy model. The lab includes an unknown action probe to show that absence of a rule is not converted into accidental permission.

9. Least Privilege

Least privilege means giving each role only the permissions required for its owned task. It is not “few permissions” in the abstract. The evidence must connect permissions to task ownership and must flag an adjacent privilege that is unnecessary for that role.

10. Vertical boundaries

A vertical privilege boundary separates actions with different authority levels. In the fixture, an Editor may write a file but may not manage workspace membership. Granting member.manage to Editor expands authority vertically and must be visible in review evidence.

11. Horizontal boundaries

A horizontal boundary separates resources at the same apparent privilege level. A Viewer in workspace w1 must not read a file in workspace w2 merely because Viewer includes file.read. Role permission and resource scope must both be satisfied.

12. The enforcement point

The authoritative enforcement point is the synthetic server-side policy evaluator. The UI may choose not to show an action, but hiding a button is not the control. A direct synthetic request is still evaluated against the same policy.

13. Mental model

Use this flow: authenticated subject → policy input → authorization decision → protected action. The deny path is a first-class branch. Audit evidence records what was observed; it does not transform a local observation into a universal security claim.

14. Baseline matrix

Start with the smallest policy that supports the owned tasks. Viewer receives read permissions. Editor adds file write. WorkspaceAdmin adds member-management permissions. Every role remains workspace-scoped in the fixture. Do not add permissions “for future convenience.”

15. Positive evidence

A positive probe shows that a required task still works. Examples include a Viewer reading a same-workspace file and an Editor writing a same-workspace file. Positive evidence is necessary because a policy that denies everything is not useful.

16. Negative Evidence

Negative probes are equally important. The lab checks an unknown action, cross-workspace access, and an Editor attempting member management. The result should show the exact deny classification rather than only a generic test failure; the vertical deny token is VERTICAL_PRIVILEGE_DENIED.

17. Mutation: a new action without a rule

Introduce a synthetic action such as project.archive without adding an allow rule. The expected result is DEFAULT_DENY. This demonstrates the policy contract without relying on a framework default that has not been configured or tested.

18. Mutation: vertical over-grant

Temporarily add member.manage to Editor. The action can now become technically allowed, but the least-privilege audit must classify the role as over-granted. Authorization correctness includes reviewing what the policy should allow, not only what the evaluator mechanically allows.

19. Mutation: UI hiding is not enforcement

Mark member.manage as hidden in the synthetic UI for Editor, then issue the direct local request. The server-side policy still denies it. This separates presentation from authorization enforcement.

20. Authorization Decision Matrix v1

For each material row, capture: Subject/Role, Resource Scope, Action, Explicit Allow Rule, Default Decision, Enforcement Point, Positive Probe, Negative Probe, Evidence, and Residual Policy Question. A blank decisive field means the final bounded decision is not yet supported.

21. Observation versus inference

“Request X returned HORIZONTAL_SCOPE_DENIED in the local fixture” is an observation. “The production service is safe from horizontal privilege escalation” is an unsupported inference. Keep these categories separate in the artifact.

22. Model fit: where RBAC becomes awkward

Role alone may be insufficient when policy depends strongly on resource relationships, tenant ownership, attributes, time, or workflow state. This lesson does not teach full ABAC or ReBAC. It requires you to mark the residual policy question instead of creating role explosion.

23. Transfer Case

A synthetic support system has Agent, Supervisor, and Billing roles over tenant-scoped tickets. Build a new minimal matrix. Identify at least one decision where role alone is insufficient because ticket tenant, assignment, or another resource relationship matters.

24. Assessment checkpoints

You should be able to state the authorization decision tuple, explain Default Deny, justify the minimal permission set, distinguish horizontal from vertical denial, identify the authoritative enforcement point, and defend a changed-context decision without copying the workspace matrix.

25. Freshness and source boundary

Current authorization guidance in this lesson is bound to the frozen OWASP-AUTHORIZATION snapshot retrieved on 2026-09-02. Its review due date is 2026-10-02. Query 1 occurs before that date, so no source-scope expansion or external re-search is required.

26. Completion standard

Complete the lesson only when positive and negative probes are both preserved, the deny path is visible, least-privilege drift is detectable, observations are separated from inference, the matrix is complete, and the transfer decision is made independently. Production policy acceptance remains outside this lesson.