tegwick
6c4fcaf9ae
All checks were successful
- NK-WP-0036 finished: native onboarding journey completed by the operator. - NK-WP-0037-T02 waits on key-cape: Authelia 4.38 rejects every human prompt=login flow (auth_time precedes request registration). - identity-provisioner: read-only autocomplete=username field on the setup form (submitted value ignored) and an HTTPS sign-in link on completion. - NK-WP-0041 tracks the fixes and routes Authelia/user-engine findings. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 299762@bnt-lap001 Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e
116 lines
5.4 KiB
Markdown
116 lines
5.4 KiB
Markdown
---
|
|
id: NK-WP-0037
|
|
type: workplan
|
|
title: "Bind password setup to the Vergabe company welcome and sign-in"
|
|
domain: infotech
|
|
repo: net-kingdom
|
|
status: active
|
|
flavor: implementation
|
|
owner: codex
|
|
topic_slug: netkingdom
|
|
created: "2026-09-12"
|
|
updated: "2026-09-23"
|
|
related: [VERGABE-WP-0019, KEY-WP-0033, RAPPS-WP-0014]
|
|
state_hub_workstream_id: "15f59624-ab25-5894-9b05-1e6b261749e5"
|
|
---
|
|
|
|
## Keep the company return inside the one-use setup grant
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
id: NK-WP-0037-T02
|
|
status: wait
|
|
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.
|