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
81 lines
2.9 KiB
Markdown
81 lines
2.9 KiB
Markdown
---
|
|
id: KEY-WP-0007
|
|
type: workplan
|
|
title: "User-engine portal OIDC relying-party integration"
|
|
domain: infotech
|
|
repo: key-cape
|
|
status: finished
|
|
owner: codex
|
|
topic_slug: netkingdom
|
|
created: "2026-07-27"
|
|
updated: "2026-07-29"
|
|
depends_on:
|
|
- KEY-WP-0005
|
|
- USER-WP-0020
|
|
state_hub_workstream_id: "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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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.
|