From 9d1ae01b75f009868938c0e87c1109d460ce893b Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 27 Jul 2026 22:48:58 +0200 Subject: [PATCH] Define user-engine portal integration boundary --- docs/user-engine-provisioning-contract.md | 34 +++++++++++++++++++ ...user-engine-portal-platform-integration.md | 4 +-- 2 files changed, 36 insertions(+), 2 deletions(-) create mode 100644 docs/user-engine-provisioning-contract.md diff --git a/docs/user-engine-provisioning-contract.md b/docs/user-engine-provisioning-contract.md new file mode 100644 index 0000000..3da1c42 --- /dev/null +++ b/docs/user-engine-provisioning-contract.md @@ -0,0 +1,34 @@ +# user-engine identity provisioning contract + +user-engine is authoritative for user, tenant membership and lifecycle intent. +NetKingdom is authoritative for provider subjects, credentials, password +policy, MFA factors and authentication sessions. KeyCape projects verified +authentication facts; flex-auth decides whether an actor may change intent. + +The NetKingdom adapter implements user-engine's provider-neutral +`IdentityProvisioningPort`. Every operation has an idempotency key and +correlation ID. Provisioning creates or links an LLDAP subject, initializes +privacyIDEA eligibility without enrolling a factor, and returns the external +subject. Password and factor enrollment remain user-facing KeyCape handoffs. + +Lifecycle order is: + +1. Commit user-engine intent and an outbox event atomically. +2. Claim the event and call the provider with its stable idempotency key. +3. Store the provider subject and completion evidence. +4. Retry ambiguous failures; reconcile provider and domain state periodically. + +Suspension disables provider authentication before reporting external +completion. Reactivation preserves the same subject. Deprovisioning first +removes active sessions and factors, then tombstones or removes the directory +subject according to retention policy. A failed downstream action remains +retryable and visible; it never rolls back authoritative audit history. + +The adapter receives scoped provider credentials only through runtime secret +references. Neither browsers nor the user-engine domain receive directory, +MFA, KeyCape or mail-administration credentials. + +Externally managed identities record provider, immutable external subject, +ownership (`platform` or `customer`), provisioning mode (`managed`, +`federated`, or `jit`), and last-observed freshness. Future SCIM and corporate +directory adapters use the same lifecycle results and conflict rules. diff --git a/workplans/NK-WP-0023-user-engine-portal-platform-integration.md b/workplans/NK-WP-0023-user-engine-portal-platform-integration.md index 88343d0..7b52f2f 100644 --- a/workplans/NK-WP-0023-user-engine-portal-platform-integration.md +++ b/workplans/NK-WP-0023-user-engine-portal-platform-integration.md @@ -25,7 +25,7 @@ as the first acceptance case. ```task id: NK-WP-0023-T01 -status: todo +status: done priority: high state_hub_task_id: "8d96aa5e-9801-4d76-9140-d6076a4f2942" ``` @@ -41,7 +41,7 @@ now so later enterprise directories do not require a domain rewrite. ```task id: NK-WP-0023-T02 -status: wait +status: progress priority: high state_hub_task_id: "89fe51aa-f351-4763-a358-3eec79f28350" ```