WEB / CASE tenant-and-object
Identity is verified. Where is report permission?
Read subject, action, object, tenant and relationship checks for Duru and Ekin’s Atlas reports.
Observation file
Duru is a member with verified tenant atlas. Ekin owns report-atlas-02. Requested action is report.read. This teaching policy allows owner or reviewer reads in the same tenant; it is not a universal RBAC rule.
Explain the decision
Successful login does not change Duru’s ownership relationship. The fixture expects DENY with reason OWNER_REQUIRED. Ekin as a reviewer may read an Atlas report; tenant mismatch takes precedence for an Orion report.
An audit allow applies only to that subject, action, object and context. A visible UI button is not a server decision. Field-level representation control may require a separate check.
Control and verification
Compare own read, other owner, other tenant, missing context and unknown action in the fixed policy matrix. Deny branches withhold the protected body. Audits record minimal actor/action/object/decision fields without session secrets.
YOUR TURN
Work through this story.
Predict the outcome, find the evidence boundary, and explain it in your own words.
Why does Duru’s verified Atlas context not make this report.read decision an allow? Read the policy and object record together.
Selected observations from the synthetic case file
- subject
- Duru
- role
- member
- verified tenant
- atlas
- object
- report-atlas-02
- owner
- Ekin
- action
- report.read
- teaching policy
- same tenant AND (owner read OR reviewer read)
- Verified login permits reading every Atlas report.
- DENY / OWNER_REQUIRED; Duru is neither the owner nor a reviewer.
- DENY / TENANT_MISMATCH; report-atlas-02 belongs to another tenant.
Read the explained answer
DENY / OWNER_REQUIRED; Duru is neither the owner nor a reviewer. — The decision follows evaluation of subject/action/object/tenant/relationship on the server. Successful login does not change ownership metadata. OWNER_REQUIRED is this fixture’s reason, not a universal RBAC outcome.
An allow record is observed for Ekin reading an Atlas report. Why is “a reviewer can read reports in every tenant” unsupported?
- The reviewer role makes the tenant check unnecessary in this policy.
- A visible UI button means the server also allows the other tenant.
- The allow is scoped to that context; an Orion object encounters the tenant mismatch check first.
Read the explained answer
The allow is scoped to that context; an Orion object encounters the tenant mismatch check first. — The false generalization erases the observed allow’s subject/action/object/context scope. Read role, tenant and object relationship together; UI visibility is no substitute.
Write positive and negative regression checks for this teaching policy. What do you check in deny bodies and audit fields?
Read the explained answer
Preserve own-read conditions and same-tenant reviewer read as positive checks. Compare other-owner/member, other-tenant, absent verified context and unknown-action branches as separate deny checks. A deny response withholds the protected body. Audits retain required actor/action/object/decision fields without session secrets. This matrix checks only the supplied teaching policy, not every RBAC system.
□ Are legitimate own/reviewer reads retained as positive controls?
□ Are ownership, tenant, verified context and unknown-action deny branches separate?
□ Do denies withhold protected bodies and audits omit secrets?
□ Is the outcome bounded to the teaching policy?
Lessons connected to this case · 23
Return to the case with these lesson concepts. Connections do not add observations to the case record; they help examine its responsibilities together.