Add a workplan for workload sign-in diagnosis.
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

NK-WP-0051 records who shows the uid, the group names, and whether this login verified a one-time code.

Assistant: grok
Assistant-Session: 01a13b2d-5f6d-7a32-b2c9-384625c55ca6
This commit is contained in:
tegwick 2026-10-14 22:25:51 +02:00
parent e99c3e9791
commit 4717863554

View file

@ -0,0 +1,164 @@
---
id: NK-WP-0051
type: workplan
title: "Show who a workload sign-in actually is"
domain: infotech
repo: net-kingdom
status: ready
flavor: planning
owner: codex
topic_slug: netkingdom
created: "2026-10-14"
updated: "2026-10-14"
related:
- MASON-WP-0011
- NK-WP-0034
- NK-WP-0042
---
# Show who a workload sign-in actually is
## Goal
Make the next attended workload login show the uid, the directory group
names, and whether this authorization verified a one-time code, before
OpenBao accepts or refuses it.
MASON-WP-0011 took a day because those three facts were split across the
account site, Authelia, and OpenBao. The account site stayed on
`bernd.worsch-3` while `bao login` reused another Authelia session. OpenBao
then said only `claim "groups" does not match any associated bound claim
values`. A user with no one-time password never reached that refusal.
## Boundaries
NetKingdom orchestrates this. It does not re-implement the issuer, the
account page, or OpenBao.
| Change | Owner |
| --- | --- |
| Pre-redirect diagnosis and the uid on the KeyCape auth log | key-cape |
| Account-site uid and Authelia uid as two lines | user-engine |
| Authelia session hint, memberOf preview, negative-login fixture name | net-kingdom |
| Fresh browser for `bao login`, receipt fields, `capabilities-self` on the lane token | ops-mason, applied by railiance-platform |
| Role choice on the OpenBao UI. `platform-admin` stays the admin role | railiance-platform |
Out of scope: widening `ops-mason-survey`, attaching
`workload-kv-read-reuse-surface-runtime` to admin entity
`4a1f663c-0621-0483-edd0-f852274f4b6b`, `verbose_oidc_logging`, and any log
of a token, authorization code, email address, or one-time password.
Group display names and the uid are the diagnosis. They are not secret.
## Write the diagnosis contract
```task
id: NK-WP-0051-T01
status: todo
priority: high
```
Write `docs/sign-in-diagnosis.md`. It is the contract the other tasks
implement. It names three facts, for this authorization and no earlier one:
- the uid KeyCape resolved from Authelia `preferred_username`
- the directory group display names copied from that uid's `memberOf`
- whether this authorization verified a one-time code (`aal2`) or did not
(`aal1`)
The contract also says where each fact appears: the page before KeyCape
returns to the application, the KeyCape log line (`client_id` and uid),
the account site (account-site uid and Authelia uid on separate lines),
and the ops-mason receipt (uid and the OpenBao error text, no token).
Done when that document is the only copy of the field list.
## KeyCape shows the principal before the callback
```task
id: NK-WP-0051-T02
status: wait
depends_on: [NK-WP-0051-T01]
blocked_on: message-from:key-cape
blocking_reason: "After T01. key-cape implements the pre-redirect page and the uid log line. NetKingdom does not edit the issuer."
priority: high
```
key-cape shows the three facts before it redirects to the application, and
adds the uid and `client_id` to the existing auth log line. A groups
refusal from OpenBao then follows a screen that already named the uid.
Acceptance is a deployed key-cape image. The log line contains no token,
code, email, or one-time password. This repo records the image digest in
the T01 document.
## Account site shows both sessions
```task
id: NK-WP-0051-T03
status: wait
depends_on: [NK-WP-0051-T01]
blocked_on: message-from:user-engine
blocking_reason: "After T01. user-engine renders the account-site uid and the Authelia uid as two lines. NetKingdom does not edit the account page."
priority: high
```
`users.coulomb.social` keeps the account-site session. It adds the current
Authelia uid beside it. Authelia's cookie domain stays `coulomb.social`.
This repo only points at that requirement from `docs/sign-in-diagnosis.md`.
## Preview directory groups for a uid
```task
id: NK-WP-0051-T04
status: todo
depends_on: [NK-WP-0051-T01]
priority: high
```
Add a read-only preview in this repo that prints one uid's `memberOf`
display names. No mail, no password, no one-time password. Matching those
names to an OpenBao role stays a metadata read in ops-mason.
Name one negative-login fixture in the T01 document: a uid that is not in
`reuse-surface-hub-writers`, is not a platform admin, and will hold a
one-time password. Do not create that user in git.
## Enroll the negative-login factor
```task
id: NK-WP-0051-T05
status: wait
depends_on: [NK-WP-0051-T04]
blocked_on: human
blocking_reason: "After T04 names the fixture uid. Founder enrolls its one-time password at https://pink-account.coulomb.social/, realm coulomb."
priority: medium
```
The founder enrolls the factor. Enrollment is not `aal2`. A later login is
`aal2` only when that login asks for the one-time password.
## Hand the OpenBao proof back to its owners
```task
id: NK-WP-0051-T06
status: wait
depends_on: [NK-WP-0051-T01]
blocked_on: message-from:ops-mason
blocking_reason: "After T01. ops-mason and railiance-platform own the caller proof and the UI role choice. NetKingdom does not change OpenBao."
priority: medium
```
Ask ops-mason and railiance-platform to do four things, and no others:
- `bao login` for a named role uses a fresh browser profile, or prints the
address and waits. It does not reuse the default Authelia session.
- The verifier receipt records the uid and the OpenBao error text. It
still records no token and no KV value.
- The lane policy gains a generated `sys/capabilities-self` read so the
proof does not call `sys/capabilities` with a root token.
- The OpenBao UI can select the workload role. The existing button remains
role `platform-admin`.
`ops-mason-survey` stays read-only. The workload policy stays off the
admin entity. This task is done when both repos have accepted those four
items, not when this repo edits them.