Assignment
Create synthetic administrator, support, and read-only roles across two tenants, with one service identity and a revoked user.
Build sequence
- Define allowed reads, proposals, approvals, and writes for each role.
- Test direct APIs, retrieval, cached responses, and queued jobs against the matrix.
- Rotate the sandbox service secret and revoke a user during a task.
- Write the operational steps for diagnosing identity failures.
Acceptance checks
- The service identity cannot grant users broader access than their role allows.
- Revocation affects subsequent protected actions.
- Audit records distinguish requesting user, approving user, and executing service.
Evidence to keep
Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.
Guided workshop: carry identity through every boundary
For Northstar, define Alice as an Alder operator, Bob as a Birch operator, and Morgan as an Alder reviewer. Operators can read their tenant's ordinary tickets and draft replies. Only reviewers can approve a proposed update. Nobody can read another tenant's private contract.
Write the access matrix before implementing it:
| Actor | Alder ticket | Birch ticket | Approve Alder draft |
|---|---|---|---|
| Alice | Read/draft | Deny | Deny |
| Bob | Deny | Read/draft | Deny |
| Morgan | Read/draft | Deny | Allow |
Build steps: resolve identity from the authenticated session, map it to tenant and roles, authorize the requested resource, scope retrieval, and check authorization again when applying an action. An SSO login establishes identity under its configured trust relationship; it does not automatically grant every application permission.
Worked escalation attempt: Alice sends {"role":"reviewer","tenant":"birch"} in the request body. The backend ignores those assertions as authority and uses its verified principal. If a worker runs under a broad service account, pass a narrowly scoped task identity or re-evaluate the original user's permissions rather than inheriting the service account's full access.
Exercise: test guessed IDs, changed tenant fields, revoked role membership, expired sessions, another user's cached answer, and a document whose permission changed after indexing. Capture both the final response and the exact context handed to the model. Denying the response after the model received forbidden text is too late.
Enterprise review: identify secrets, encrypted transport, storage encryption, audit access, retention, tenant boundaries, backup access, and permitted processing locations. Document which controls the application owns and which belong to the deployment platform or customer. A checklist is evidence of questions asked, not a legal certification or proof of compliance.
Assessment: present the matrix, test outcomes, architecture boundaries, and unresolved customer decisions. Do not label the system enterprise-ready while identity mapping, data location, or operational ownership remains an assumption.