key-cape/workplans/KEY-WP-0007-user-engine-portal-oidc-client.md

---
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.