Chapter 25 — Design studio: case intake and authorization model

Chapter 25 — Design studio: case intake and authorization model

Lesson map

Lesson 25 published. Map, example, EX049.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["25.1 Studio brief synthetic"]
  N2["25.2 State machine"]
  N3["25.3 Access matrix"]
  N4["25.4 Checking the design"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX049"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["25.1 Studio brief synthetic"]
  N2["25.2 State machine"]
  N3["25.3 Access matrix"]
  N4["25.4 Checking the design"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX049"]

[Learning outcomes and connection]
    |
    v
[25.1 Studio brief synthetic]
    |
    v
[25.2 State machine]
    |
    v
[25.3 Access matrix]
    |
    v
[25.4 Checking the design]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX049]

Learning outcomes and connection

After this studio you can (1) design a case-intake state machine for a multi-tenant response service; (2) define an access matrix combining role, tenant and case state; (3) specify audit events for every transition; and (4) review a peer's design for illegal transitions and privilege escalation. It integrates Chapters 2, 10, 18 and 21–24 and prepares Chapters 27, 31 and 44.

25.1 Studio brief (synthetic)

HVSS operates a shared response service. Central responders may work cases of any client that has delegated authority to HVSS; client responders may see and act only within their own tenant; some cases are shared (affecting several tenants) and need a structure in which each tenant's data remains separated. Deliverables: state machine, access matrix, audit event list, a check script and a peer review record. The three HVSS clients, the city council, the water utility's billing department and the hospital trust, are the tenants in this brief.

25.2 State machine

States: intake → triage → investigating → contain_requested → contain_approved → containing → recovering → closed, with rejected (not an incident) and merged (duplicate). Rules: every state except closed, rejected and merged has a timeout that escalates (Chapter 31); closed can be reopened only by a duty manager with a reason; merged keeps a pointer to the surviving case and never deletes data.

Compared with the seven states of Lab 2, this machine separates investigating from triage and containing from the approval state. It also adds the two exits rejected and merged, which the check script must treat as terminal along with closed.

25.3 Access matrix

Authorisation is a function of (role, tenant relation, case state, action). Express it as a table and a predicate:

For a shared case, the matrix applies per tenant partition: a client responder from tenant 1 sees the shared case's common summary and tenant-1 partition only.

25.4 Checking the design

Encode transitions and the matrix, then check properties mechanically, as in Lab 2: no path to containing without contain_approved; no role both requests and approves the same request; no read or action across tenant boundaries without delegation; every transition emits an audit event with actor, tenant, case, from/to state and reason. A short check over all (role, tenant, state, action) combinations — a few hundred cases — is cheap and catches errors that review misses. Finding F1 in the peer review below is the kind of error this sweep catches.

25.5 Worked example: peer review findings

A peer reviewing the first draft found: (F1) client approvers could approve containment of targets in a shared case belonging to another tenant, because the approval predicate checked case tenant instead of target tenant; (F2) merged transition allowed by client responders across tenants, which would have moved one client's data into another's case; (F3) no audit event on reopen. Fixes: approval predicate on the target's tenant; merge restricted to same-tenant cases or HVSS duty managers with both tenants' delegation; audit event added. Each fix gained a test.

25.6 Errors and limits

• Checking authorisation on the case instead of the action's target.
• Merge and split operations that move data across tenants.
• Missing audit events on rare transitions.
• Review without mechanical checking.

The HVSS peer review found the first three errors in one draft. F1 checked the case tenant rather than the target tenant, letting a client approver act on another tenant's hosts in a shared case. F2 allowed a cross-tenant merge that would have moved one client's data into another client's case. F3 left the rare reopen transition without any audit event at all. Each fix gained a test so that the mechanical check would catch a recurrence.

Exercises — chapter 25

EX049 — Encode and check. Objective: mechanical verification. Inputs: the matrix in 25.3. Steps: write a Python predicate allowed(role, relation, action, target_tenant, actor_tenant) and a loop that asserts no cross-tenant action is allowed without delegation; include the F1 fix. Expected evidence: code and output. Rubric: 3 = correct predicate, exhaustive loop, F1 covered; 2 = partial; 1 = attempt; 0 = none.

EX050 — Review a design. Objective: peer review. Inputs: a variant where client responders may also approve if no client approver responds within 30 min. Steps: identify the properties violated and propose a safer alternative. Expected evidence: findings and proposal. Rubric: 3 = identifies separation-of-duties violation (requester may approve own request), proposes escalation to HVSS duty manager or deputy client approver; 2 = partial; 1 = accepts; 0 = none.

Chapter synthesis

A case-intake design is a state machine plus an access predicate over role, tenant, state and target. Check it mechanically, audit every transition, check authorisation on the action's target and use peer review to find what checks miss.

Continue studying — chapter 25 of 50

← Chapter 24 · Course chapter index · Chapter 26 →

Continue to the next authored lesson.