Vord

Enhancement Proposal

Proposal: Admin impersonation ("log in as user")

Motivation

Support organizations demand it: to debug what a user sees, a support admin needs to be that user for a bounded moment. Done naively it is the most abusable feature an IdP can ship — an unaudited path to any account. The incumbents all offer it gated and logged; Vord's backlog has helpdesk reset/unlock (proposal 0016) but no impersonation at all. This proposal adds it with the properties that make it defensible: impersonated tokens are cryptographically distinguishable, the grant is relationship-authorized, the session is bounded and killable, and nothing about it exists before its audit trail does.

Design

  1. Impersonation is a token exchange minting a composite-identity token. The support admin's token is exchanged (the RFC 8693 seat, ADR-0014) for a token whose sub is the target principal and whose act (actor) claim names the impersonating admin — the standard composite-identity shape. There is deliberately no way to mint an impersonated token that looks like the user's own: the act claim and a dedicated acr value (decision 3) are always present, so relying parties, audit, and Vör-side policy can always tell.

  2. Authorization is a Forseti relation plus realm policy. "May impersonate principals of realm R (or org O)" is an ordinary relation (ADR-0006), granted through delegated administration (proposal 0016) and therefore reviewable, time-boxable, and SoD-constrainable like any IGA grant (ADR-0030). Per-realm policy then picks the ceremony: consent mode (the user approves each session — the default), notify mode (the user is informed, suited to workforce support), or break-glass mode (recorded justification, second-admin approval — for locked-out-user cases where consent is impossible).

  3. Impersonated tokens are floor-assurance and step-up-proof. They carry a dedicated acr value (registered in the token spec when this ships) that no step-up policy accepts: MFA-gated and elevated operations refuse it by construction (ADR-0020), because an admin proving their identity must never satisfy a check about the user's. Scopes are capped by a realm-configured impersonation allowlist — support surface, not full account power.

  4. Bounded and killable. Impersonation sessions get a short, realm-capped TTL, their own sid (ADR-0044), and no refresh tokens — expiry ends them, and one status-list entry kills one mid-flight (ADR-0044's machinery unchanged).

  5. Audited end to end, visible to the user. Session start/end, every minted token, the justification, and the approver are events (ADR-0022); the target user sees impersonation sessions — clearly marked — in self-service session management (proposal 0010), and the admin console reports them (proposal 0018). Two dependencies pin the milestone at M6: a feature whose whole defense is its audit trail must not exist before that trail is queryable (M5), and the token-exchange machinery it mints through is built with the SAML milestone (ADR-0017) — a one-off exchange built earlier would duplicate M6's work.

Alternatives considered

  • Password-reset-based support access (reset, log in, hand back): rejected — destructive, invisible to audit, and indistinguishable from account takeover, which is the pattern this proposal exists to kill.
  • Plain token minting without act (a true "become the user"): rejected — indistinguishability is the abuse case, not a feature.
  • Read-only screen-share tooling instead: out of scope — often the right support answer, but not an identity-platform primitive, and it does not cover API-level reproduction.

Graduation criteria

  • An authorized admin obtains an impersonated token only through the exchange, in the realm's configured mode; an unauthorized attempt is refused and audited (abuse-case test, ADR-0028).
  • An impersonated token is rejected by every step-up-gated operation and by scopes outside the allowlist (abuse-case test).
  • Kill works: revoking the impersonation sid invalidates its tokens within the freshness budget.
  • The session appears in the audit projection and the user's session view, marked as impersonation.

Backward compatibility

  • The act claim and the impersonation acr value are registered in the token spec (specs/vord-token-v0) when this ships — additive while the format is v0/unstable; verifiers that ignore act see a valid but floor-assurance token, which is the safe reading.
  • Rides existing seats end to end (RFC 8693, Forseti relations, sid revocation, event stream): no new architecture, one new grant profile.

Open questions

  • Cross-organization impersonation in B2B (proposal 0015/0016 interplay): can a tenant admin impersonate into a customer org, or only org-local admins?
  • Does consent-mode approval ride notification delivery (proposal 0011) or an in-app prompt at next login?
  • The default TTL cap (minutes-order) — pinned when the realm policy schema lands.