ADR-0013: User Identity Lifecycle¶
Context¶
Authentication is delegated to OIDC with JIT provisioning (ADR-0011) and administration
uses MANAGE_USERS (ADR-0012). GAP-02 needs the full account lifecycle: how users are
created (including onboarding before first login), how leavers are handled without losing
attribution (STR-009), and how unique identity is maintained (Part 11 / Annex 11). The
User entity is referenced by every approval and audit event, so its identity and states
must be stable and history-preserving.
Decision¶
- Identity anchor: a user is 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.
- Provisioning — pre-provisioning (invite) plus JIT:
- An admin with
MANAGE_USERSmay invite a user (by email / IdP identifier) and assign roles before first login. The first successful OIDC login binds the stable subject id to the invited record. - A user authenticating with no matching record is JIT-provisioned (ADR-0011), with no access until assigned roles.
- Email is the matching key only for not-yet-bound invited records. Once a subject id is bound it is authoritative; later email changes do not rebind identity.
- Lifecycle states:
invited→active→deactivated, with reactivation back toactivereusing the same record (no duplicate identity). - Deactivation is a state change, never deletion. It blocks authentication/ authorization in LQMS independently of the IdP, but the user's authorship, approvals, and audit events remain intact and attributable; prior approvals are not retroactively invalidated (they were valid when made). LQMS maintains this status itself, so "left a project" (remove role) and "left the company" (deactivate) are distinct.
- No shared human accounts. Each human user is a distinct individual; machine/service identities are the separate OAuth2 client path (REQ-AUTH-011).
- Pending obligations on deactivation (required-approver in open reviews, owned drafts) are surfaced to a scope administrator for reassignment — workflows are not silently blocked.
- Erasure of personal data is out of scope here — governed by the retention/GDPR decision (GAP-06). Deactivation ≠ erasure.
Consequences¶
- The
userrecord carries: internal id, issuer, subject id (nullable until bound), email, display name, lifecycle state. Invite/bind/deactivate/reactivate flows and a binding step on first login are required. - Email-based matching for invited records carries a known identity-linking caveat (email change/reuse before binding); mitigated by binding to the subject id as soon as it is known and auditing the bind.
- All lifecycle actions are audited (REQ-AUD-001).
- Erasure/pseudonymization vs. immutable attribution is deferred to GAP-06; until then, deactivation preserves all attribution.
Requirements¶
Introduces STR-018 and the REQ-USR group (pending requirements baseline v1.1).