Sequence identity portal before stack cutover
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

This commit is contained in:
tegwick 2026-07-27 22:30:02 +02:00
parent 71b1a7b028
commit abc92a1197
2 changed files with 143 additions and 1 deletions

View file

@ -4,11 +4,15 @@ type: workplan
title: "Cut over NetKingdom identity to railiance01 and retire CoulombCore" title: "Cut over NetKingdom identity to railiance01 and retire CoulombCore"
domain: infotech domain: infotech
repo: net-kingdom repo: net-kingdom
status: ready status: backlog
owner: codex owner: codex
topic_slug: netkingdom topic_slug: netkingdom
created: "2026-07-27" created: "2026-07-27"
updated: "2026-07-27" updated: "2026-07-27"
depends_on:
- USER-WP-0020
- NK-WP-0023
- KEY-WP-0004
state_hub_workstream_id: "3dadddeb-4cec-48e2-9c2c-788b26dd6e93" state_hub_workstream_id: "3dadddeb-4cec-48e2-9c2c-788b26dd6e93"
--- ---
@ -25,6 +29,11 @@ railiance01, while Authelia, LLDAP, and privacyIDEA DNS still points to
CoulombCore. Retirement is forbidden until state equivalence, end-to-end CoulombCore. Retirement is forbidden until state equivalence, end-to-end
login, backup restoration, and an observed rollback window pass. login, backup restoration, and an observed rollback window pass.
This cutover intentionally waits until the reusable user onboarding portal
completes the Binky tenant-admin flow. That supplies the human login/MFA and
lifecycle evidence needed to judge which identity stack is authoritative
before state migration or retirement begins.
## T01 - Freeze the migration contract and inventory both stacks ## T01 - Freeze the migration contract and inventory both stacks
```task ```task

View file

@ -0,0 +1,133 @@
---
id: NK-WP-0023
type: workplan
title: "Integrate and deploy the user-engine onboarding portal"
domain: infotech
repo: net-kingdom
status: ready
owner: codex
topic_slug: netkingdom
created: "2026-07-27"
updated: "2026-07-27"
depends_on:
- USER-WP-0020
- KEY-WP-0004
---
# NK-WP-0023 - user-engine portal platform integration
Provide the NetKingdom-owned adapters and production integration required by
`USER-WP-0020`, using the Binky tenant-admin onboarding from `KEY-WP-0004-T02`
as the first acceptance case.
## T01 - Define source-of-truth and provisioning contracts
```task
id: NK-WP-0023-T01
status: todo
priority: high
```
Ratify lifecycle sequencing and compensation across user-engine, LLDAP,
KeyCape, privacyIDEA, flex-auth, email verification, audit, and outbox
delivery. user-engine owns user-domain and membership intent; NetKingdom IAM
owns credentials, authentication factors, coarse authentication claims, and
provider subjects. Define externally-provisioned/federated ownership metadata
now so later enterprise directories do not require a domain rewrite.
## T02 - Implement the NetKingdom identity provisioning adapter
```task
id: NK-WP-0023-T02
status: wait
priority: high
```
Implement idempotent create/link/suspend/reactivate/deprovision operations for
the lightweight LLDAP + privacyIDEA stack behind user-engine's
`IdentityProvisioningPort`. Use scoped service identity and approved secret
transport. Never expose directory admin credentials to the browser or
user-engine domain. Add reconciliation, retry, compensation, and drift
reporting rather than assuming a distributed transaction.
## T03 - Integrate KeyCape login, claims, and MFA handoffs
```task
id: NK-WP-0023-T03
status: wait
priority: high
```
Register the portal OIDC client with authorization code + PKCE, configure
callback/logout routes, verify issuer/audience/tenant/assurance claims, and
provide safe password and MFA enrollment/recovery handoffs. Preserve
platform-root separation and ensure tenant administration never implies
platform authority.
## T04 - Integrate authorization, email, audit, and events
```task
id: NK-WP-0023-T04
status: wait
priority: high
```
Define and implement flex-auth resources/actions for self, tenant-admin, and
platform-admin operations; route verification/invitation email without making
mailbox ownership an authorization fact; correlate user-engine, IAM,
authorization, and platform audit records; and connect durable outbox
delivery with replay and dead-letter evidence.
## T05 - Deploy on reef-railiance
```task
id: NK-WP-0023-T05
status: wait
priority: high
```
Package the portal as a managed platform workload on the default
`rail-kubernetes` path on `reef-railiance`, with Postgres, OpenBao-backed
runtime references, NetworkPolicies, TLS ingress, backups, observability,
resource limits, rollout/rollback, and availability evidence. Do not place
this stateful platform control surface on scale-to-zero Knative.
## T06 - Prove role-scoped administration and failure safety
```task
id: NK-WP-0023-T06
status: wait
priority: high
```
Run end-to-end conformance for registration, login, MFA, tenant creation,
first-admin bootstrap, invitations, suspension/reactivation, cross-tenant
denial, platform-admin-only actions, provider outages, replay/idempotency,
backup restore, and reconciliation after partial failure.
## T07 - Complete KEY-WP-0004 through the reusable portal
```task
id: NK-WP-0023-T07
status: wait
priority: high
```
Use the production portal to onboard
`bernd.worsch@binky-hedgehog.com` into `tenant:friendly:binky`, complete
OIDC/PKCE + MFA, and verify the Binky-only tenant-admin token and lifecycle
controls. Publish only non-secret evidence to `KEY-WP-0004-T02/T07`, then
finish that workplan.
## T08 - Document enterprise integration extension points
```task
id: NK-WP-0023-T08
status: wait
priority: medium
```
Document later adapters for customer IdPs/directories, SAML/OIDC federation,
SCIM, JIT provisioning, directory group mapping, customer-owned offboarding,
and conflict/freshness rules. Keep `NK-WP-0011` demand-triggered; this task
defines compatibility seams, not enterprise implementation.