tegwick
c19eabc4ae
Records the user-engine digest and that Authelia's authentication_level is not assurance, since KeyCape checks the one-time code. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 1041694@bnt-lap001 Assistant-Session: 7af0bb68-ac4a-4ce3-8639-24ddd84c0b52
4.6 KiB
Sign-in diagnosis contract
Status: accepted contract for NK-WP-0051. This document is the only copy of the field list; other repositories link here instead of restating it.
Why
MASON-WP-0011 took a day because three facts about one login were split
across the account site, Authelia, and OpenBao. OpenBao said only
claim "groups" does not match any associated bound claim values. Every
surface below shows the same three facts, named the same way, for this
authorization request and no earlier one.
Fields
| Field | Meaning | Source |
|---|---|---|
uid |
The uid KeyCape resolved for this request | Authelia preferred_username (fallback sub), as KeyCape's Authelia adapter resolves it |
groups |
Directory group display names, sorted | That uid's LLDAP memberOf, reduced to display names |
assurance |
aal2 if this request verified a one-time code, else aal1 |
KeyCape: a one-time code verified within this request. Not MFAVerified alone, which is also true when a reused aal2 session satisfies the request |
client_id |
The relying party the login returns to | The authorization request |
openbao_error |
OpenBao's error text, verbatim | ops-mason receipt only |
assurance is per request. A reused session that was aal2 earlier is
aal1 here unless this request asked for and verified the one-time code.
Enrolling a factor is not aal2.
Authelia's own authentication_level is not assurance. KeyCape checks the
one-time code through privacyIDEA, so Authelia reports level 1 even for an
aal2 sign-in. Surfaces take assurance from KeyCape (the request or the
token it issued), never from Authelia's /api/state.
Never shown or logged
Tokens (ID, access, refresh, OpenBao), authorization codes, email
addresses, one-time passwords or seeds, passwords, session cookies, and raw
memberOf DNs. Group display names and the uid are the diagnosis; they are
not secret.
Where each field appears
| Surface | Fields | Owner | Task |
|---|---|---|---|
| KeyCape page before the redirect to the application. Opt-in per client (registration flag, default off), enabled first for the OpenBao client. One action: continue, plus how to sign in as someone else | uid, groups, assurance, client_id |
key-cape | NK-WP-0051-T02 |
| The existing KeyCape auth log line | client_id, uid, assurance |
key-cape | NK-WP-0051-T02 |
Account site users.coulomb.social: account-site uid and current Authelia uid on two separate lines. Authelia's cookie domain stays coulomb.social |
uid (twice, labelled by session), assurance of the account-site session |
user-engine | NK-WP-0051-T03 |
lldap_admin.py groups --user <uid> (read-only preview) |
uid, groups |
net-kingdom | NK-WP-0051-T04 |
ops-mason verifier receipt for an attended bao login |
uid, openbao_error (and assurance when known) |
ops-mason | NK-WP-0051-T06 |
Matching groups to an OpenBao role stays a metadata read in ops-mason.
Negative-login fixture
Fixture uid: signin-probe-negative.
- not a member of
reuse-surface-hub-writers - not a platform admin (
net-kingdom-admins) - holds a one-time password (enrolled by the founder in NK-WP-0051-T05 at
https://pink-account.coulomb.social/, realmcoulomb)
The user is never created or described with credentials in git. A
successful diagnosis of this fixture shows uid=signin-probe-negative,
groups without reuse-surface-hub-writers, assurance=aal2, and then the
OpenBao groups refusal.
Evidence
| Item | Value |
|---|---|
| key-cape page and log line | live 2026-10-15: forgejo.coulomb.social/coulomb/key-cape@sha256:cdec9dd7c515f7e0a6169fc3fa560ee2cc47bf40d899755dec808c362f5ce010 (source 8c6c071, includes af3b1b0). signInDiagnosis: true set on live openbao-admin 2026-10-15 (sso/keycape-config rv 71655453 → 75372162, byte-preserving, issuer restarted). Accepted 2026-10-15: founder bao login -method=oidc -path=netkingdom role=platform-admin showed the page and completed |
| user-engine two-session lines | live 2026-10-15: forgejo.coulomb.social/coulomb/user-engine@sha256:1e6547c40c93c49f01438edcf76c20f561ccebc110220bae020723505aa56c70 (source 7f1db71, pinned in rapp-user-engine a42c68f). Also shows the account-site session assurance. Founder accepted: platform-root · aal2 and Authelia platform-root |
ops-mason receipt, fresh-browser login, capabilities-self proof |
ops-mason fca5591 (MASON-WP-0012); live proof pending MASON-WP-0012-T04 |
sys/capabilities-self grant and UI workload-role select |
railiance-platform 0f0282a (RPF-WP-0057); CCR-2026-0045 approval/apply and overlay deploy pending RPF-WP-0057-T02/T04 |