codex
270a065383
These workplans exist only in the retired local hub. Their random pre-ADR-007 identifiers are refused by C-06 as stale references, so they cannot be registered. Deriving from the canonical record id takes no identity from anything: central does not hold them and the old ids die with the cache. Records central already holds were deliberately left untouched. Refs CUST-WP-0068-T06 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2583210@bnt-lap001 Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
2.9 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | depends_on | state_hub_workstream_id | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| KEY-WP-0007 | workplan | User-engine portal OIDC relying-party integration | infotech | key-cape | finished | codex | netkingdom | 2026-07-27 | 2026-07-29 |
|
24db4178-705c-5b09-b7db-ee7a345d71a0 |
KEY-WP-0007 - User-engine portal OIDC relying-party integration
Register and prove the reusable user-engine portal as a strict KeyCape public
client. This is the authentication edge required by NK-WP-0023-T03; it does
not move user-domain or authorization ownership into KeyCape.
Register the static portal client
id: KEY-WP-0007-T01
status: done
priority: high
state_hub_task_id: "7d722cae-bf6d-52e0-80f4-cc51e9fb42f0"
Register user-engine-portal for authorization code with mandatory S256 PKCE,
exact callback URIs and only openid profile email groups. No wildcard,
implicit flow, client secret, or dynamic registration is allowed.
Deploy and verify the live client
id: KEY-WP-0007-T02
status: done
priority: high
state_hub_task_id: "0b222062-4352-5ae6-9e85-95787af08409"
Update the railiance01 KeyCape configuration without exposing its signing key or backend credentials. Verify discovery, authorize redirect validation, unregistered callback denial and successful token exchange through the portal.
Prove claims and MFA isolation
id: KEY-WP-0007-T03
status: done
priority: high
state_hub_task_id: "859e7322-71dc-58cc-9f44-6f869c2d0b59"
Prove issuer, audience, tenant, groups, roles and assurance claims are verified by the portal and that tenant administration does not imply platform-root. Complete the Binky user/MFA acceptance through the reusable browser path.
2026-07-27: The live client accepts only the exact portal callback and rejects
an unregistered callback with invalid_profile_usage. The portal begins an
S256 PKCE flow and hands authentication to Authelia. LLDAP tenant envelope
mapping now recognizes unambiguous tenant:<kind>:<slug>:users|admins groups;
ambiguous multi-tenant directory envelopes fail closed to no explicit tenant.
2026-07-28: suspension now fails closed at both token exchange and
/userinfo; the deployed key-cape:909bb32 image refuses subjects carrying
the netkingdom-suspended directory group. The portal admin surface uses this
through the provider-neutral lifecycle API. The human Binky MFA/claims
acceptance remains the final part of this task.
2026-07-29 complete: the reusable browser path issued the Binky password
handoff, completed privacyIDEA TOTP enrollment, and returned through the
portal authorization-code flow. /api/v1/me verified the canonical issuer,
user-engine-portal audience, tenant:friendly:binky, Binky-only groups,
roles user + tenant-admin, and AAL2 assurance with pwd + otp and
mfa: true. The same session was denied administration of
tenant:platform and tenant:coulomb. All workplan tasks are complete.