net-kingdom/workplans/NK-WP-0037-vergabe-company-welcome.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
NK-WP-0037	workplan	Bind password setup to the Vergabe company welcome and sign-in	infotech	net-kingdom	finished	implementation	codex	netkingdom	2026-09-12	2026-09-23	VERGABE-WP-0019 KEY-WP-0033 RAPPS-WP-0014	15f59624-ab25-5894-9b05-1e6b261749e5

Keep the company return inside the one-use setup grant

id: NK-WP-0037-T01
status: done
priority: high
state_hub_task_id: "61f71d46-8218-5c50-8b1b-5cd1c096d9d3"

PasswordSetupGrants now accepts an exact tenant-to-HTTPS-entry mapping, copies it at startup, and stores the destination inside the recipient's grant when issuing a setup link. Only successful password setup releases the company link. The service-authenticated provisioning tenant selects it; browser return fields are ignored. No recipient, credential or setup token travels to the product. The product performs its own fresh login and explicit account confirmation.

Sixteen provisioner tests pass, including real HTTP issuance/completion, malicious return fields, replay/expiry, other tenants and configuration validation. Existing setup links remain process-local and expire on restart.

Bind and release the provider and company client

id: NK-WP-0037-T02
status: done
priority: high
state_hub_task_id: "8921691b-e7a2-543c-8189-3abc24de1bc7"

Register public client vergabe-demo-company with only openid/profile/groups, authorization_code and the exact callback https://vergabe-teilnahme.coulomb.social/demo-company/accounts/oidc/callback/. No client-declared tenant, secret, public registration or MFA downgrade. Preserve all existing KeyCape configuration using the established guarded client-registration lane. KEY-WP-0033 retains fresh-login propagation and the shared issuer rollout preflight.

Set PASSWORD_SETUP_TENANT_RETURNS to map tenant:trial:demo-company to https://vergabe-teilnahme.coulomb.social/demo-company/. Publish and pin the provisioner image with its 25m/32Mi request unchanged. Preserve the password setter, credential references and directory contents. Recipient sign-in and provider-required MFA need an attended acceptance; no credential capture or operator impersonation. VERGABE-WP-0019-T06 owns product acceptance and RAPPS-WP-0014 retains application placement and recovery.

2026-09-12 release prepared: source 48a75b1, published provisioner digest sha256:55f744cc9bc2ec3fe23eb7175fa4b7bfcc7a29469d9b9a1a8eaefc75d790dfc6. Sixteen tests pass against that runtime image. The exact public client helper's server dry run passes with unrelated Secret/config bytes preserved; candidate patches are in the KeyCape and provisioner directories. Deployment waits for the attended shared-issuer window. See railiance-apps/docs/vergabe-demo-company-sso-rollout.md. No live configuration, credential, recipient data or application session was changed.

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.

Attended recipient sign-in 2026-09-23 — blocked on fresh-login

Test recipient bernd.worsch-99 (NK-WP-0036-T05) opened the Vergabe demo company in a private window. The sign-in failed with KeyCape's "Sign-in could not be completed" page, in this sequence:

1. KeyCape logged auth_start for vergabe-demo-company at 19:40:54.
2. The recipient authenticated at Authelia at 19:41:03.
3. Authelia registered the authorization request at 19:41:04.17 and refused it: "prompt was set to 'login' but auth_time … happened before the authorization request … was registered, indicating that the user was not re-authenticated". It issued no code.
4. KeyCape's code exchange failed (token_exchange_error, then auth_failed).

Authelia 4.38 registers a prompt=login request only after the login, so every human fresh-login flow through KeyCape fails. The earlier "fresh-login forwarding" checks were redirect-only and never completed a real login. Portal sign-in does not request a fresh login and works.

Ownership: fresh-login propagation belongs to key-cape (KEY-WP-0033). The Authelia version and configuration belong to the reference deployment. There are two candidate fixes:

• KeyCape enforces freshness itself (max_age/auth_time) instead of forwarding prompt=login;
• move to an Authelia release whose flow handling supports prompt=login (not yet verified upstream).

T02 waits on key-cape. MFA enrollment and account confirmation were not reached. Rerun the same recipient once the fix is live.

Attended rerun 2026-09-23 — T02 done

key-cape shipped the fix under KEY-WP-0033-T02 (key-cape@11ce29a, image key-cape@sha256:8dc35801…). The operator rolled it out on railiance01, and it is pinned at net-kingdom 8ee0f8b. Post-rollout checks:

• verify-openbao-client.sh passed.
• The Vergabe callback with PKCE returned 302; a wrong callback and missing PKCE each returned 400.
• prompt=login now reaches Authelia as max_age=10.

Recipient bernd.worsch-99 then completed the journey in a new private window:

• KeyCape auth_start at 20:16:36, auth_success at 20:17:28 and token_issued at 20:17:29 for vergabe-demo-company.
• Vergabe logged /accounts/oidc/callback/ 302, the confirmation page 200, and the confirmation POST 302.

No MFA was involved, by design. P06 permits AAL1 when privacyIDEA authoritatively reports no active factor; privacyIDEA logged the no-factor token lookup at 20:17:28. The operator decided that MFA stays a user preference for Vergabe Teilnahme for now (ADR-0016). That supersedes the "provider-required MFA" wording above. Workload-requested MFA is NK-WP-0042.