---
id: NK-WP-0036
type: workplan
title: "Restore native portal login and tenant-onboarding integration"
domain: infotech
repo: net-kingdom
status: active
owner: the-custodian
topic_slug: netkingdom
created: "2026-09-11"
updated: "2026-09-11"
related: [KEY-WP-0007, RAPPS-WP-0014, VERGABE-WP-0019]
state_hub_workstream_id: "6e1358d6-87e4-52e7-b3dd-09abdc48cefc"
---

The demo-company operator login returns `invalid_profile_usage`, feature
`client_id`, description `unknown client_id`. The approved public client from
KEY-WP-0007 is absent from live `sso/keycape-config`. The bootstrap generator
also omits it; this is a demonstrated regeneration hazard, not proof of which
historical change removed the live registration. User requests retry/repair
under continued demo-tenant onboarding authority.

## Preserve the existing registration in source and prepare the bounded repair

```task
id: NK-WP-0036-T01
status: done
priority: high
state_hub_task_id: "7f30efcb-beac-5843-bca7-a5cbc1c715cc"
```

Keep `user-engine-portal` public, authorization-code/S256 PKCE, exact callback
`https://users.92-205-62-239.nip.io/oidc/callback`, and only
`openid profile email groups`. Add the existing declaration to the bootstrap
generator and test equality with `register-user-engine-portal.py`.
`portal-client-rollout.py` adds only a missing declaration, preserving other
configuration bytes and Secret data. It refuses changed/duplicate registrations,
controller ownership, wrong cluster and stale UID/resourceVersion. Secret values
stay in memory/child stdin and never enter output, arguments or persisted files.
Four synthetic regression tests pass. No credentials or roles are granted.

## Restore and verify the live login entry point

```task
id: NK-WP-0036-T02
status: done
priority: high
state_hub_task_id: "8a3c3e91-d604-59ee-9d15-f79223667780"
```

Inspect and server-dry-run the exact observed Secret revision, apply the bounded
patch, read back unchanged unrelated data, and restart the existing KeyCape
deployment to load configuration. Keep the current image and 25m resources.
Record readiness and valid-client authorize redirect, invalid-callback and
missing-PKCE refusal. Reopen a fresh portal login only after positive preflight.
Actual human login and demo tenant creation continue in RAPPS-WP-0014-T02;
this repair alone is not evidence of tenant existence or operator entitlement.

If native verification fails, retain the exact non-secret failure and reconcile
the current resource revision; do not replay a stale complete Secret. Hand any
remaining actionable defects to live records before finishing this plan.

Live repair succeeded on 2026-09-11. The exact missing client was added without
changing unrelated Secret data. KeyCape restarted at its existing image and
resources. Valid authorization redirects to Authelia; wrong callback and missing
PKCE are refused. The operator subsequently authenticated as platform-root and
reached the platform form. See docs/evidence/2026-09-11-native-portal-repair.md.

## Repair and verify the portal-to-tenant policy contract

```task
id: NK-WP-0036-T03
status: progress
priority: high
state_hub_task_id: "378b03b3-aedc-50c3-8de7-94064794582b"
```

The real form submission returned provisioning_unavailable, correlation
corr_d41f417c61713afc7ddea08f. Tenant Engine logs show POST /tenants returning
403 before its create transaction. Its PDP recognizes only tenant-engine and
flex-auth; the shipped portal calls as user-engine. Tenant read is also missing
from that policy despite the shipped endpoint requiring it.

Register the existing user-engine service for only non-platform tenant create
and read in flex-auth/examples/tenant-engine. Keep ServiceAccount caller auth
enforced. Preserve denied grants, lifecycle, plan and guardrail mutations.
In user-engine, preserve display name and correlation id in the create request,
and map authority denial to the existing redacted 403 path, proving that no
administrator is created after a tenant-authority denial.

Run owner regression suites, publish through existing Forgejo image CI, pin and
roll only the Tenant Engine PDP and rapp-user-engine runtime, and verify the
actual allowed/denied contract with authenticated consumer calls. Then reconcile
native demo tenant existence before retrying the operator form. RAPPS-WP-0014
retains actual tenant onboarding and product placement; this workplan does not
claim tenant existence or application readiness from component tests alone.