key-cape/workplans/KEY-WP-0033-vergabe-fresh-login.md
tegwick f67d98ff63 Classify open workplans with flavor (CUST-WP-0072).
Set flavor on open workplans from origin/prose/status. Copy existing
depends_on aliases only. Do not promote residuals.

Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
2026-09-14 15:50:43 +02:00

71 lines
3.3 KiB
Markdown

---
id: KEY-WP-0033
type: workplan
title: "Preserve fresh-user authentication for the Vergabe company handoff"
domain: infotech
repo: key-cape
status: active
flavor: implementation
owner: codex
topic_slug: netkingdom
created: "2026-09-12"
updated: "2026-09-12"
related: [VERGABE-WP-0019, NK-WP-0037, USER-WP-0025]
state_hub_workstream_id: "144dd430-1a09-51e1-9aad-e799ee86c338"
---
## Forward login freshness to the actual authentication provider
```task
id: KEY-WP-0033-T01
status: done
priority: high
state_hub_task_id: "fe05486b-f079-503b-ade1-fca65bf64b34"
```
KeyCape parsed prompt=login and max_age but dropped them before Authelia.
Forward these through the provider-neutral AuthRequest and the Authelia adapter.
Absent values retain ordinary SSO behavior. Handler and adapter regressions
cover forced login and zero/nonzero maximum age. Full Go suite passes after
correcting the existing example-count regression: the example file already
contains four service clients and the admitted human approver client.
## Publish, preflight and prove the fresh recipient boundary
```task
id: KEY-WP-0033-T02
status: progress
priority: high
state_hub_task_id: "7b58f08c-6063-554a-8700-a1edbc805ca4"
```
Publish the exact source and validate current live config before replacing the
single issuer instance. The live image is dcebd46/digest 7ff54c54; current main
also contains startup validation and tenant provenance changes documented in
docs/operations.md. Preserve all unrelated client, credential and MFA policy
configuration. NK-WP-0037 adds the exact public Vergabe callback with no tenant
assertion or MFA downgrade. Confirm prompt=login reaches Authelia through the
live redirect, wrong callbacks and missing PKCE fail, and the actual recipient
uses their own identity. Provider restart invalidates pending in-memory logins;
USER-WP-0025-T03 still owns full provider sign-out coordination.
2026-09-12 release prepared: source 8d4336e, Forgejo image run 45 succeeded,
digest sha256:5f10f36a5da23ce1aaf3df9b84a8ff98d7926f34ceaa19e63bd3356adb68e01a.
The exact client-registration and deployment server dry runs pass. The runtime
is unchanged. Await the attended window required by docs/operations.md; the
complete packet is railiance-apps/docs/vergabe-demo-company-sso-rollout.md.
2026-09-12 attended rollout executed after explicit operator approval. KeyCape
and password setup are Ready on the prepared digests; exact public client
registration was CAS-applied (config resourceVersion 60123977) with unrelated
config bytes/Secret data preserved. Existing portal and product client both
pass fresh-login forwarding, wrong-callback and missing-PKCE checks (6 checks).
Vergabe Helm revision 2 is Ready; identity migration completed, both PVCs remain,
and requests remain 60m CPU/256Mi memory. Eleven live product checks pass:
company welcome, anonymous gate, no-store, secure scoped CSRF, POST/CSRF-only
login start, native issuer redirect, private company/media protection and
invalid callback/confirmation rejection. Initial readback showed zero accounts,
identity mappings and staff accounts. Native invited-user sign-in/MFA and
confirmation are now requested from the operator; no user credential was used
by the agent. Recovery and two-user acceptance remain their existing tasks.
Evidence: railiance-apps/docs/evidence/2026-09-12-demo-company-sso-live.md.