Record the completed fresh login and account switch.

Assistant: grok
Assistant-Session: 01a0d25d-d358-7e13-b84a-d007fbb7e34f
This commit is contained in:
tegwick 2026-09-25 01:49:42 +02:00
parent 004a72cd5c
commit f16559280c
4 changed files with 53 additions and 21 deletions

View file

@ -0,0 +1,22 @@
# Fresh login and account switch — 2026-09-24
Issuer image already running:
`forgejo.coulomb.social/coulomb/key-cape@sha256:8dc35801d1d2b0905a43530c40b1fed0107fc179141fe5b2b614c52c01714fc9`
(Forgejo image run 69, source `11ce29a`). No further rollout was made.
The founder completed the browser journeys and reported that both worked.
Issuer telemetry for 23:40–23:46 UTC, event type and client only:
| Time | Event | Client | Result |
|---|---|---|---|
| 23:42:25 | `mfa_failed` | `user-engine-portal` | failure |
| 23:43:20 | `auth_success` then `token_issued` | `user-engine-portal` | success |
| 23:44:45 | `auth_success` then `token_issued` | `user-engine-portal` | success |
| 23:45:37 | `auth_success` then `token_issued` | `user-engine-portal` | success |
| 23:46:10 | `token_exchange_error`, then `auth_failed` | `vergabe-demo-company` | failure |
| 23:46:38 | `auth_success` then `token_issued` | `vergabe-demo-company` | success |
No `stale_upstream_authentication` in the window. Each portal success was a new
`auth_start`, so the earlier session was not silently reused. The Vergabe
token was issued after one failed code exchange, on a second attempt. Already
issued application JWTs are not revoked by provider logout.

View file

@ -174,13 +174,14 @@ workload or customer data, any sign the transcript left the workstation, or a
planned key rotation. The same workplan removes the problem class by giving
agents a cluster identity that cannot read these objects at all.
## Unreleased fail-closed startup changes (read before the next rollout)
## Fail-closed startup changes shipped in the live image
The deployed image at the time of writing is
`sha256:7ff54c54e63ee172ae9e6e7fd2da96e427352f712343d74626ee6fe0f6f82611`, built
from `dcebd46`. The changes below on `main` postdate it, all affect startup or
issuance, and **all fail closed**, so they land together on the next rollout and
a mistake in either presents as a refusal rather than as a warning.
The live issuer is
`sha256:8dc35801d1d2b0905a43530c40b1fed0107fc179141fe5b2b614c52c01714fc9`,
Forgejo run 69, source `11ce29a`, confirmed running on 2026-09-25. The changes
below shipped in that image. They fail closed. The 2026-09-24 Vergabe journey
completed after one token-exchange failure; see
`docs/evidence/2026-09-24-fresh-login-and-account-switch.md`.
**1. Browser clients reject service-identity fields (`74b35b6`, KEY-WP-0028).**
Config validation now rejects `serviceSubject` or `roles` on a client whose
@ -212,9 +213,8 @@ or is absent (`stale_upstream_authentication`). This changes nothing for clients
that do not ask for freshness. The proof is a completed fresh-login journey,
not a redirect check.
None of these has been exercised against a running issuer. The honest proof for both is
a live boot with the new binary, which belongs to the attended rollout window and
not to a session running against production on its own.
The live boot is the image above. A further rollout is not required for these
three changes.
## What is not claimed

View file

@ -4,12 +4,12 @@ type: workplan
title: "Preserve fresh-user authentication for the Vergabe company handoff"
domain: infotech
repo: key-cape
status: active
status: finished
flavor: implementation
owner: codex
topic_slug: netkingdom
created: "2026-09-12"
updated: "2026-09-23"
updated: "2026-09-25"
related: [VERGABE-WP-0019, NK-WP-0037, USER-WP-0025]
state_hub_workstream_id: "144dd430-1a09-51e1-9aad-e799ee86c338"
---
@ -34,7 +34,7 @@ contains four service clients and the admitted human approver client.
```task
id: KEY-WP-0033-T02
status: progress
status: done
priority: high
state_hub_task_id: "7b58f08c-6063-554a-8700-a1edbc805ca4"
```
@ -83,6 +83,11 @@ than the KeyCape request, max_age needs one within that age, and a missing
auth_time fails closed (event `stale_upstream_authentication`). Known edge: a
user whose Authelia login is under 10s old at request time is not re-prompted
and is refused rather than admitted. Also fixed the stale example-count test left
by 651625c/1620ce2 (6 service + 1 human). Full Go suite passes. Not deployed:
needs a release plus the attended window, then a completed rerun of the
bernd.worsch-99 journey. Redirect-only checks do not count as proof.
by 651625c/1620ce2 (6 service + 1 human). Full Go suite passes.
The image was already the live issuer
(`sha256:8dc35801`, Forgejo run 69, source `11ce29a`). No second rollout.
2026-09-24 23:46 UTC the founder completed the Vergabe journey: one
`token_exchange_error`, then `auth_success` and `token_issued` for
`vergabe-demo-company`. No `stale_upstream_authentication`. Receipt:
`docs/evidence/2026-09-24-fresh-login-and-account-switch.md`.

View file

@ -4,12 +4,12 @@ type: workplan
title: "Browser authentication recovery and confirmed shared sign-out"
domain: infotech
repo: key-cape
status: active
status: finished
flavor: implementation
owner: codex
topic_slug: key-cape
created: "2026-09-12"
updated: "2026-09-12"
updated: "2026-09-25"
state_hub_workstream_id: "49b0cd1d-fb9d-5351-99eb-9be9143a092d"
---
@ -37,7 +37,7 @@ MFA downgrade, global JWT revocation claim or inferred workload entitlements.
```task
id: KEY-WP-0034-T02
status: progress
status: done
priority: high
state_hub_task_id: "4c836ddf-2eb8-528a-b63f-8499f3a6cbf2"
```
@ -54,6 +54,11 @@ Source verification: Full Go suite passed; final OIDC/config tests passed after
Recovery is deployed in KeyCape 4d8b8fe, User Engine e54b6ee and Vergabe c067993
(Helm revision 3). All three are Ready. Six provider checks, eleven product
checks and six fresh anonymous Chromium checks pass, including actual provider
logout POST and return to the portal without test overrides. Real-user identity
switching is still awaiting operator evidence; no authenticated/MFA acceptance
is inferred. Detailed receipt: railiance-apps/docs/evidence/2026-09-12-account-recovery-live.md.
logout POST and return to the portal without test overrides. Detailed receipt: railiance-apps/docs/evidence/2026-09-12-account-recovery-live.md.
2026-09-24 23:42–23:45 UTC the founder completed the account switch. The issuer
recorded one `mfa_failed` for `user-engine-portal`, then three separate
`auth_start` → `auth_success` → `token_issued` sequences. A silent reuse of
the previous portal session would not have produced those new successes.
Provider logout still does not revoke already issued application JWTs.
Receipt: `docs/evidence/2026-09-24-fresh-login-and-account-switch.md`.