--- id: NK-WP-0023 type: workplan title: "Integrate and deploy the user-engine onboarding portal" domain: infotech repo: net-kingdom status: active owner: codex topic_slug: netkingdom created: "2026-07-27" updated: "2026-07-28" depends_on: - USER-WP-0020 - KEY-WP-0004 state_hub_workstream_id: "c652e4ba-6520-4b30-966f-4fb5659439db" --- # 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: done priority: high state_hub_task_id: "8d96aa5e-9801-4d76-9140-d6076a4f2942" ``` 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: progress priority: high state_hub_task_id: "89fe51aa-f351-4763-a358-3eec79f28350" ``` 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. 2026-07-28 implementation evidence: `identity-provisioner` now implements the provider-neutral lifecycle API over LLDAP and runs as a non-root, internal-only service in `sso`. Its directory credential remains confined to that pod; user-engine receives only a namespace-local bearer token. NetworkPolicy allows only user-engine to call it and only LLDAP/DNS egress. A live create/replay/delete conformance run returned `resumed: false`, then `resumed: true`, and removed the disposable subject. Reconciliation, compensation, and drift reporting remain. ## T03 - Integrate KeyCape login, claims, and MFA handoffs ```task id: NK-WP-0023-T03 status: progress priority: high state_hub_task_id: "76289890-6e6e-45ea-90dc-d3d58eee8b62" ``` 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. 2026-07-27 implementation evidence: `user-engine-portal` is registered as a public static KeyCape client with an exact callback and S256 PKCE. The portal is live at `https://users.92-205-62-239.nip.io`, has a trusted ACME certificate, begins the KeyCape/Authelia flow, and rejects an unregistered callback. KeyCape image `key-cape:e8b4ede` maps an unambiguous `tenant:::users|admins` directory group envelope into the tenant and coarse tenant-admin claims while refusing ambiguous multi-tenant mapping. 2026-07-28 update: KeyCape image `key-cape:909bb32` fails closed for directory subjects in `netkingdom-suspended`: authorization-code exchange consumes the code and returns a safety rejection, while `/userinfo` rejects previously issued tokens. Unit and profile suites pass. Live Binky MFA acceptance remains. ## T04 - Integrate authorization, email, audit, and events ```task id: NK-WP-0023-T04 status: wait priority: high state_hub_task_id: "6ce33c92-031a-4f23-8ee2-108451b394fe" ``` 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: progress priority: high state_hub_task_id: "4ef00e05-1259-4c76-a8ef-ec40b5facd1c" ``` 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. Implementation evidence (2026-07-27): the internal-only portal foundation is running on `reef-railiance` as `Deployment/user-engine` with dedicated healthy `Cluster/user-engine-pg`, default-deny NetworkPolicies, immutable directly imported image `user-engine:portal-c27012a`, and successful `/readyz` probes. Public ingress remains intentionally absent until T03 supplies the verified KeyCape OIDC edge. Forgejo OCI publication is pending restoration of the OpenBao package-publisher capability; no credential was bypassed or exposed. 2026-07-28 update: public TLS ingress and KeyCape OIDC are active. The current `user-engine:portal-e23674d` deployment is healthy with the dedicated CNPG cluster, and the companion `identity-provisioner:dbf7cfd` deployment is healthy behind namespace-scoped credentials and default-deny policy. Registry publication, backup/restore evidence, metrics, and automated rollback remain. ## T06 - Prove role-scoped administration and failure safety ```task id: NK-WP-0023-T06 status: wait priority: high state_hub_task_id: "96a7cd2b-6cab-47ab-a899-44bc0f6da58c" ``` 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. 2026-07-28 evidence: deployed-path health, service authentication, directory creation, replay-safe linking, tenant user/admin group creation, and cleanup passed. The test also detected and corrected newline handling for mounted Kubernetes secrets before any identity was created. The broader negative, outage, suspension, restore, and browser/MFA matrix remains. ## T07 - Complete KEY-WP-0004 through the reusable portal ```task id: NK-WP-0023-T07 status: progress priority: high state_hub_task_id: "a574dcec-f7cd-417b-aeaa-5392a7428241" ``` 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. 2026-07-28: the deployed versioned portal API created the Binky tenant-admin user and membership and provisioned/linked its LLDAP identity. The provider correctly reports `password_setup_required`. During this flow a newline in the mounted trusted-proxy Secret proved HTTP-incompatible; user-engine `0ef2ae5` normalizes runtime transport whitespace, has 105 passing tests, and is live. LLDAP SMTP is not configured, so first-password handoff and MFA/claim acceptance remain rather than falling back to an operator-set password. ## T08 - Document enterprise integration extension points ```task id: NK-WP-0023-T08 status: wait priority: medium state_hub_task_id: "7ef8e1f5-1a0e-4a34-9535-708e3146ae72" ``` 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.