Software Requirements: User Identity & Lifecycle¶
Introduced in requirements baseline v1.1 (GAP-02, ADR-0013).
| ID | Requirement | Trace |
|---|---|---|
| REQ-USR-001 | A user shall be a unique individual identity anchored to a stable OIDC subject (issuer + subject); email and display name are cached claims that may change without affecting identity or the attribution of past actions. (refined by ADR-0063: the identity KEY is the subject ALONE — LQMS faces exactly one issuer by construction (corporate IdPs broker through the bundled Keycloak), so the unique constraint moves from (issuer, subject) to (subject); issuer is retained as recorded PROVENANCE, not a lookup key. This removes the host-change orphaning failure; multi-issuer federation, if ever real, re-enters the key via its own ADR.) |
STR-016, STR-018; ADR-0013, ADR-0063 |
| REQ-USR-002 | An administrator with MANAGE_USERS may pre-provision (invite) a user before first login (by email/IdP identifier) and assign roles in advance; the first successful OIDC login shall bind the stable subject id to the invited record. |
STR-018; ADR-0013, ADR-0011, ADR-0012 |
| REQ-USR-003 | A user authenticating with no matching invited or existing record shall be JIT-provisioned, with no access until assigned roles. | STR-018; ADR-0013, ADR-0011 |
| REQ-USR-004 | Email shall be the matching key only for not-yet-bound invited records, and only when the authentication token asserts a verified email (email_verified): an unverified/self-asserted email shall not bind a pre-staffed invite (it shall be JIT-provisioned as a fresh account with no inherited roles). Once a subject id is bound it is authoritative and later email changes shall not rebind identity. |
STR-018; ADR-0013, ADR-0011 |
| REQ-USR-005 | A user shall have a lifecycle state (invited, active, deactivated); deactivation shall block authentication and authorization in LQMS independently of the IdP. | STR-003, STR-018; ADR-0013 |
| REQ-USR-006 | Deactivation shall be a state change, never deletion: the user's authorship, approvals, and audit events shall remain intact and attributable, and prior approvals shall not be retroactively invalidated. | STR-009, STR-018; ADR-0013, REQ-AUD-001 |
| REQ-USR-007 | A deactivated user shall be reactivatable, reusing the same record (no duplicate identity). | STR-018; ADR-0013 |
| REQ-USR-008 | Shared/generic human accounts shall not be permitted; each human user is a distinct individual identity. Machine/service identities use the separate OAuth2 client path. | STR-009, STR-018; ADR-0013, REQ-AUTH-011 |
| REQ-USR-009 | On deactivation the user's pending obligations (required-approver in open reviews, owned drafts) shall be surfaced to a scope administrator for reassignment, and shall not silently block workflows. | STR-007, STR-018; ADR-0013 |
| REQ-USR-010 | User lifecycle actions (invite, bind, deactivate, reactivate) and role-assignment changes shall produce audit events. | STR-009, STR-018; ADR-0013, REQ-AUD-001 |
| REQ-USR-011 | Erasure of a user's personal data shall be governed by the retention/data-protection decision (GAP-06); deactivation is not erasure. | STR-018; ADR-0013 |