net-kingdom/docs/evidence/2026-09-11-native-portal-repair.md
tegwick c8ad7a85ea
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
docs: record verified identity provisioner credential repair
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
2026-09-11 22:00:37 +02:00

78 lines
4.7 KiB
Markdown

# Native portal login and tenant-onboarding repair — 2026-09-11
Owner: NK-WP-0036. Actual tenant/product admission remains RAPPS-WP-0014.
The approved public `user-engine-portal` client was absent from live KeyCape.
The bounded helper repaired only that missing registration in sso/keycape-config.
Secret UID `2e94519d-1550-41c7-9701-2efe47fe1fd3`, resourceVersion
`58747126``59999030`; unrelated configuration bytes and Secret data preserved.
The full bootstrap generator was not run. Its source now retains the existing
client declaration; four synthetic helper/bootstrap tests pass.
KeyCape rollout succeeded with its prior image
`sha256:7ff54c54e63ee172ae9e6e7fd2da96e427352f712343d74626ee6fe0f6f82611`
and 25m CPU request. Read-only verification uses
`sso-mfa/k8s/keycape/verify-user-engine-portal.py`: valid S256 authorize redirects
to Authelia; wrong callback is refused with redirect_uri, missing PKCE with
missing_pkce. The first probe incorrectly expected code_challenge for the latter;
the probe expectation was corrected to the implementation's documented error.
The operator then authenticated natively as platform-root and reached the tenant
creation form (browser observation at 18:35:42 UTC). Their manual submission
returned provisioning_unavailable, correlation
`corr_d41f417c61713afc7ddea08f`. Tenant Engine logged POST /tenants 403 before its
store-create call. That establishes a downstream denial, not an identity-provider
outage. No tenant existence is claimed without native readback.
The deployed portal calls Tenant Engine as user-engine. Its PDP policy had no
such subject and also lacked the tenant.read action now required by the endpoint.
NK-WP-0036-T03 tracks the minimal policy integration, adapter error mapping,
immutable CI image promotion and live positive/negative verification. Human
credentials, session cookies and the chosen administrator's private contact
information are excluded from this record.
Local validation: Flex Auth make test (including race tests), 27 policy tests and
35 fixtures pass; actual registry-enriched create request allows policy v2.
User Engine make test: 169 tests, 3 optional integration skips, layer check passed;
regression proves authority 403 reaches the browser as redacted 403 without
creating an administrator. Source fixes: flex-auth dd8dd51, user-engine 3c85e56.
CI succeeded: Flex Auth smoke 159/image 160, User Engine smoke 116/image 117.
Tenant PDP Helm revision 3 now serves
sha256:05a03a8790c2210c48ea92391441c77ddf640d0cd32f5ec09838f5393171fcbd.
User Engine now serves
sha256:9369d6709269395751a8db301820dd8d04160d7126c3c8f509a70341d409fde8.
Both are ready at their prior 25m and 50m requests. Nine live checks from the
Tenant Engine consumer confirm intended allow/deny outcomes and missing-token
401. Native User Engine adapter readback returns demo-company not found, so the
failed form submission left no tenant. A fresh native operator login was opened
for the continued tenant onboarding in RAPPS-WP-0014-T02.
At 19:03:18 UTC the operator's second native tenant-form submission returned 200.
Native operator readback and the deployed User Engine adapter confirm
`tenant:trial:demo-company`, display `demo-company`, lifecycle active, version 1.
The tenant administration page confirms the chosen first administrator exists
with invited account status. No private contact address is recorded here.
Ordinary demo users, application deployment and onboarding remain RAPPS-WP-0014.
The observation helper mistakenly collected full browser storage every five
seconds; Playwright opened temporary pages for previously visited origins.
After the operator reported the repeated page activity, the helper was stopped
and changed to cookie-only persistence. The confirmed tenant submission was not
repeated. This was helper-induced UI disruption, not evidence of a tenant failure.
A subsequent Create login failed before directory creation because the provisioner's
LLDAP admin login returned 401. Reloading the old credential did not repair it.
The operator then ran the reviewed identity-provisioner-reconcile.py apply with
the current provider password entered only at its hidden terminal prompt. The
sanitized receipt confirms provider_login=true, consumer_login=true and
provider_password_changed=false. Secret UID c6a9e6be-5bb5-47e6-9faa-06b8d72afec3
is unchanged; its resourceVersion advanced 51345775 to 60026132.
Independent verification after the operator receipt returned reloaded-check-passed
for directory authentication and a directory read from the provisioner. Deployment
is ready 1/1 and retains image
sha256:5b460f5ca9e329e287939f4707a2bb8d5674b7f94e24cfb5f6d790f54c3f8d06.
NK-WP-0036-T04 is complete. T05 retains structured dependency errors and functional
preflight; RAPPS-WP-0014 retains the actual native user login/password-setup proof.