# Remove an employee without leaving a usable session

Use the complete synthetic fixture below in a notebook or text file. No live target, paid service or secret is needed. Make your own decision before opening the worked assessment. Then take the implementation option below, a local project in which you repair running code until its tests pass, and keep its test output with your written answers.

A departing employee still has a signed token and a linked identity. Trace authentication and authorization through removal and recovery.

## Supplied material

```text
User U17 belongs to tenant north and has passkey P1, backup codes C, and external login subject (issuer=https://id.example.test, sub=ext-17).
Application keys accounts by exact issuer+subject, not email. Display email is shared by an unrelated account at another issuer.
At 09:00 U17 receives access token T with audience invoices-api, tenant north, exp=09:30, signed by K1. At 09:05 U17 is removed from north. The API currently authorizes using only T.tenant until expiration.
At 09:06 recovery request R proves control of the mailbox but presents no existing factor or approved recovery evidence. Support proposes linking it to the unrelated issuer because email matches.
At 09:07 signer publishes K2; K1 remains valid for already issued tokens until their expiry. At 09:08 token T2 has valid K2 signature but audience analytics-api.
At 09:09 background job J created by U17 requests an invoice export; job payload stores only user ID and tenant. Policy requires current membership at execution.
Retention policy: deleted memberships remain in an access-controlled audit record for 90 days; they must not remain active authorization facts.
```

## Task 1

Draw the source of truth for identity, session, membership and background-job authority.

Your assessment:

## Task 2

Decide T, R, the proposed link, T2 and J at the indicated times.

Your assessment:

## Task 3

Specify removal, token rollover, recovery and audit-retention tests, including a legitimate active user during K1/K2 overlap.

Your assessment:

## Task 4

Write an operational runbook that distinguishes session revocation from deleting the audit history.

Your assessment:

## Decide the fixed cases

### Decide each request at its time.

Choose from: Accept; Reject.

- T after 09:05: valid K1 signature, not expired, tenant north: ______
- Recovery R at 09:06: mailbox control only: ______
- Linking R to the unrelated issuer because the email matches: ______
- T2 at 09:08: valid K2 signature, audience analytics-api: ______
- Job J at 09:09: export for U17's stored tenant: ______

## Evidence

- Lifecycle event/decision table.
- Issuer-subject account-linking policy.
- Rollover and removal test matrix.
- Audit retention and revocation acceptance criteria.

## Rubric

Score each criterion with the anchor whose evidence your answer shows: 0, 1 or 2 points. Every anchor describes something a reviewer can point to in your work. Aim for at least 7 of 8, with no unresolved critical failure.

### 1. Separates token authenticity from current tenant membership. (2 points)

- 0 points: Allows T until 09:30 because it is validly signed.
- 1 point: Denies T after 09:05, but by a mechanism that also breaks other users, such as revoking K1.
- 2 points: T is authentic but fails the current-membership policy after 09:05; the protected operation checks current membership, or a session version or revocation list designed for it, while other users’ K1 tokens keep working.

Your score:

### 2. Recovery and linking use account-bound proof rather than email equivalence. (2 points)

- 0 points: Approves R, or links the accounts because the email matches.
- 1 point: Refuses the link but approves R on mailbox control alone, or the reverse.
- 2 points: R is refused: mailbox control is neither an existing factor nor approved recovery evidence. The link is refused because accounts are keyed by issuer and subject, and the matching email belongs to an unrelated account at another issuer. It names acceptable proof, such as passkey P1 or the backup codes.

Your score:

### 3. Rollover tests preserve legitimate overlap while rejecting wrong audiences. (2 points)

- 0 points: Rejects every K1 token at 09:07, or accepts T2.
- 1 point: Accepts K1 during the overlap and rejects T2, but has no test for a legitimate active user or for the removed user.
- 2 points: A matrix: an active user’s K1 token is accepted until it expires; K2 tokens are accepted; T2 is rejected at invoices-api for its analytics-api audience; U17’s tokens are rejected whichever key signed them; planned rollover is kept distinct from revocation after a compromise.

Your score:

### 4. Jobs reauthorize and retained history cannot confer active access. (2 points)

- 0 points: Job J runs because it was queued while U17 was a member.
- 1 point: J is denied, but the retained membership records are still readable by the authorization code.
- 2 points: J rechecks current membership when it runs and is denied; deleted memberships are kept for 90 days in an access-controlled audit record that authorization never reads; the runbook separates revoking sessions from deleting audit history.

Your score:

Critical failures (resolve before calling the case complete):

- [ ] Allows removed U17 because T has not expired.
- [ ] Links accounts solely by email.
- [ ] Accepts T2 at invoices-api.

## Implementation option: Prove deprovisioning reaches sessions and queued work

Repair exercise.py until the 18 tests pass, so a directory disable reaches current sessions and tokens, group-derived permissions and queued jobs, including after retries and restarts.

Keep: Failing and passing test output, and a note mapping the T, R, T2 and J decisions in your table to the tests that cover the same rule.

Download: https://softwaresecurity.com/downloads/projects/identity-lifecycle-510849ac517b9ec2.zip (Python 3.11+ · standard library, 18 tests). Instructions: https://softwaresecurity.com/labs/#project-identity-lifecycle

## Worked assessment (read after completing the case)

T’s valid signature and unexpired lifetime do not satisfy the current-membership policy after 09:05. Enforce current authorization facts or an explicitly designed revocation/session-version control at the protected operation. R does not satisfy the stated recovery proof; an equal email at another issuer cannot authorize linking. T2 is rejected for the wrong audience even though K2 is trusted. J is denied when it rechecks membership at execution. Preserve authorized active-user K1 tokens during the documented rollover window unless compromise requires revocation; do not confuse a planned rollover with user removal. Retained audit records are historical evidence and cannot reactivate membership.

Original teaching material: CC BY 4.0. Attribution: Software Security.