railiance-apps/docs/vergabe-demo-company-sso-rollout.md

Demo-company sign-in: executed attended rollout

2026-09-12, VERGABE-WP-0019-T06 / KEY-WP-0033 / NK-WP-0037. The operator approved and the prepared rollout was applied on 2026-09-12. All three services are Ready; Helm revision 2 serves the company welcome and NetKingdom sign-in. Native invited-user/MFA acceptance remains pending. See docs/evidence/2026-09-12-demo-company-sso-live.md.

The preparation and rollback record follows.

Component	Source	Published digest
Vergabe	8be281025bf57a7aefd1fe98a7e060f2173df5ef	sha256:2cb393608a82be2851adfc27f2bf4d8ef5d709f1b0038be5d0999e38c68b039e
KeyCape	8d4336e9448c564ac85f5f10dc75fff3c553564c	sha256:5f10f36a5da23ce1aaf3df9b84a8ff98d7926f34ceaa19e63bd3356adb68e01a
Password setup	48a75b1a5456f224b077b73af1b345473823a743	sha256:55f744cc9bc2ec3fe23eb7175fa4b7bfcc7a29469d9b9a1a8eaefc75d790dfc6

125 local application tests pass, including 27 OIDC cases; assets build and migration drift checks pass. The full KeyCape Go suite passes. Sixteen provisioner tests pass locally and against the published runtime image, including HTTP issuance/completion. Two registration-helper tests pass.

Vergabe image publication run 51 passed. Acceptance run 49 completed its test stage but failed during image export; its log stops there, so the precise export failure cause is not established. Run 52 acceptance and run 53 smoke both pass on cf50cc55338e298de56f2a6e1929848a4bfbc0ae; its only difference from 8be2810 is the generated brief. KeyCape image publication run 45 passed.

Why the shared rollout is attended

key-cape/docs/operations.md, section on the two changes after the deployed image, says the live boot "belongs to the attended rollout window and not to a session running against production on its own." The current issuer is source dcebd46 / digest 7ff54c54. The new release includes the accepted browser client startup validation and tenant provenance changes as well as this session's fresh-login forwarding. These affect the shared issuer. The existing one-replica Recreate strategy interrupts pending logins; the provisioner's in-memory setup links also expire on restart. No credential rotation is needed.

The exact client addition passed the owner's guarded server dry run against sso/keycape-config UID 2e94519d-1550-41c7-9701-2efe47fe1fd3, resourceVersion 60090393. The helper preserves unrelated configuration bytes and other Secret data, checks the changed browser-client startup constraint and refuses drift. Repeat inspection immediately before applying; the recorded revision is not a license to replay over a changed configuration.

Prepared files and execution order

1. Inspect/dry-run/apply the exact client with net-kingdom/sso-mfa/k8s/keycape/vergabe-client-rollout.py. The public client has only openid/profile/groups and one exact HTTPS callback. It declares no tenant and does not weaken the provider's MFA policy.
2. Apply net-kingdom/sso-mfa/k8s/keycape/vergabe-fresh-login.proposed.patch.yaml as a strategic patch to sso/keycape. Wait for Ready and verify discovery, existing portal authorization, invalid redirect and missing-PKCE rejection, and propagation of prompt=login to Authelia. On failure, restore the previous image and withhold product activation; preserve the client and all Secrets.
3. Apply net-kingdom/sso-mfa/k8s/identity-provisioner/company-welcome.proposed.patch.yaml to sso/identity-provisioner. Its 25m/32Mi request and credential references stay unchanged. The fixed tenant map returns successful setup to the company entry without tokens, recipient credentials or automatic product login.
4. Apply helm/vergabe-demo-company-oidc-egress.proposed.yaml. It admits only issuer HTTPS via the current public IP and its translated Traefik endpoint. Use Helm upgrade for the app, layering helm/vergabe-demo-company-sso.proposed.yaml over the existing admitted helm/vergabe-demo-company-values.proposed.yaml, with the current chart. The new mapping-table migration runs in the existing 60m/256Mi init envelope. Both current PVCs and database remain. The server-side dry run passed in the actual vergabe-demo-company namespace. Keep the 60m request and Recreate.
5. Confirm issuer connectivity from the application, welcome/CSRF/prefix/media protection and a rejected platform identity. Then the actual invited user completes fresh login and any required MFA, checks their account on the confirmation page and enters the company workflow. Do not use operator credentials or create a substitute shared Django password.

Rollback and remaining acceptance

Before application activation, all current images remain valid rollback references in the existing deployment receipt. Once OIDC accounts exist they have unusable local passwords. Disable NETKINGDOM_ENABLED or restore the prior app image to return to the interim gate; that is containment, not a credential fallback for these users. Keep the new identity table and all three data stores.

Restore the provisioner's previous image 5b460f5ca9e329e287939f4707a2bb8d5674b7f94e24cfb5f6d790f54c3f8d06 if its rollout fails. Do not rotate its directory credential or rerun historical bootstrap commands. Preserve data and the approved client configuration.

This release's native recipient/MFA acceptance is still open. RAPPS-WP-0014-T03 retains the coherent backup/isolated restore and pod-replacement proof; VERGABE-WP-0019-T04 retains two-user collaboration and pilot acceptance.

2026-09-12 attended rollout executed after explicit operator approval. KeyCape and password setup are Ready on the prepared digests; exact public client registration was CAS-applied (config resourceVersion 60123977) with unrelated config bytes/Secret data preserved. Existing portal and product client both pass fresh-login forwarding, wrong-callback and missing-PKCE checks (6 checks). Vergabe Helm revision 2 is Ready; identity migration completed, both PVCs remain, and requests remain 60m CPU/256Mi memory. Eleven live product checks pass: company welcome, anonymous gate, no-store, secure scoped CSRF, POST/CSRF-only login start, native issuer redirect, private company/media protection and invalid callback/confirmation rejection. Initial readback showed zero accounts, identity mappings and staff accounts. Native invited-user sign-in/MFA and confirmation are now requested from the operator; no user credential was used by the agent. Recovery and two-user acceptance remain their existing tasks. Evidence: railiance-apps/docs/evidence/2026-09-12-demo-company-sso-live.md.