Fix plus-address sign-in and finish NK-WP-0041

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e31f-2bcc-7051-a050-70d8cb2dfa49

workplans/NK-WP-0041-onboarding-journey-usability.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Fix onboarding-journey defects found in the 2026-09-23 human run"
 domain: infotech
 repo: net-kingdom
-status: active
+status: finished
 flavor: implementation
 owner: claude-code
 topic_slug: netkingdom
@@ -59,7 +59,7 @@ to a user; note it here if the password manager still misbehaves.
 
 ```task
 id: NK-WP-0041-T02
-status: wait
+status: done
 priority: medium
 state_hub_task_id: "83633649-3e5c-57e7-8207-609380a29c25"
 ```
@@ -260,3 +260,52 @@ explained. The plus-address filter defect remains on 4.38.
 `bernd.worsch-99` and could log in. The email address still cannot.
 That is the restored 4.38 behavior. The session closed there, with T02
 still `wait`.
+
+
+2026-09-27, third attempt: isolated diagnosis and claims-policy correction.
+Authelia 4.39 intentionally removed profile claims from default ID tokens
+([release notes](https://www.authelia.com/blog/4.39-release-notes/)). The deployed
+KeyCape commit `3b0446e` reads `preferred_username` from the verified ID token
+and falls back to `sub`; that opaque subject is not the LDAP username needed
+by privacyIDEA. The live config supplied no claims policy. This explains the
+MFA lookup failure; the old telemetry did not capture the exact lookup error.
+
+Added a KeyCape-only claims policy emitting `preferred_username`, retaining
+its existing scopes, audience behavior, one-factor policy and secret template.
+No MFA bypass was added. The regression probe at
+`sso-mfa/k8s/authelia/tests/probe_claims.py` runs an isolated real 4.39.28
+provider with disposable users/keys and completes authorization-code exchanges:
+without the policy the signed ID token omits the username; with the policy it
+contains the expected directory username. The subject is distinct in both
+cases. Both signatures and the public HTTPS issuer are checked. Scratch NTP
+startup checking is disabled so this local test does not depend on external
+clock services; production NTP configuration is unchanged. The complete repo
+config also passes 4.39.28 validation with placeholder secrets (legacy
+configuration deprecation warnings only).
+
+The operator confirmed availability for browser acceptance. Codex stopped
+Authelia before copying SQLite and verified `PRAGMA quick_check = ok`.
+Fresh rollback copy on the PVC:
+`backups/pre-4.39.28-claims-20260927T135544Z/db.sqlite3` (2,244,608 bytes).
+The old ConfigMap and deployment snapshots plus rollback helper are in
+`/tmp/nk-wp0041/` for this session. Rollback must restore the old config as
+well as the database and 4.38 image, since claims policies require 4.39.
+The claims policy and pinned 4.39.28 image were applied together.
+
+Closure evidence, 2026-09-27 (UTC):
+
+- Authelia is healthy on the declared 4.39.28 digest. The known LDAP startup
+  race caused two restarts; startup completed at 13:57:00.
+- At 13:57:44–45 both invalid-address probes (with and without `+`) returned
+  generic HTTP 401 and logged `user not found`, with no filter compile error.
+- Vergabe: KeyCape `auth_success` at 13:58:38 and authorization-code
+  `token_issued` at 13:58:39 for `vergabe-demo-company`.
+- Account portal: `auth_success` at 13:59:47 and authorization-code
+  `token_issued` at 13:59:48 for `user-engine-portal`.
+- The operator explicitly confirmed "Both sign-ins work" when asked to use
+  `bernd.worsch+99@gmail.com` in a fresh private window for both sites.
+
+T02 is done and NK-WP-0041 is finished. The scoped claims policy fixes the
+username propagation without changing MFA requirements. Transactional email
+link delivery remains the separately owned USER-WP-0035-T02 item described
+under T03; it is not a remaining task in this workplan.