vergabe-teilnahme/docs/netkingdom-sign-in.md

Company welcome and NetKingdom sign-in

VERGABE-WP-0019-T06. The isolated company instance consumes Authorization Code with S256 PKCE and a browser-bound state and nonce. It discovers endpoints from the configured HTTPS issuer, pins RS256, verifies signature/issuer/audience, time and nonce, and uses a unique (issuer, subject) record for the local user. It never merges accounts by email or directory display name.

Admission requires the exact configured tenant, tenant_source: directory, a human principal and the signed <tenant>:users membership group. Suspended, platform and emergency identities fail. This is the existing invited-company pilot rule: admitted members collaborate on all company tenders. Tenant-admin claims do not grant Django staff or superuser rights. New local users have no usable local password. Local deactivation immediately blocks existing sessions; provider-side revocation is bounded by the product's absolute five-minute session maximum (or the token expiry, whichever comes first).

The welcome page never consumes password-setup tokens. A CSRF-protected sign-in action clears the current product session and requests prompt=login. A valid callback displays the verified account and requires another CSRF-protected confirmation before creating a product session. External next and return_to parameters are not used. The callback redirects to a clean URL before displaying identity. Gunicorn access logging records the URL path without query strings. Passwords and bearer tokens are not persisted in the product.

Exact demo binding

Enable only with the registered client and the verified KeyCape fresh-login release. The currently deployed dcebd46 issuer lacks tenant_source and does not propagate fresh-login requests to Authelia; this product fails closed on it.

NETKINGDOM_ENABLED=true
NETKINGDOM_ISSUER=https://kc.coulomb.social
NETKINGDOM_CLIENT_ID=vergabe-demo-company
NETKINGDOM_CALLBACK=https://vergabe-teilnahme.coulomb.social/demo-company/accounts/oidc/callback/
NETKINGDOM_TENANT=tenant:trial:demo-company
COMPANY_DISPLAY_NAME=Demo Company

Use a public client with only openid profile groups, authorization_code, and the exact callback above. Do not add a client-declared tenant or a weaker MFA override. Keep the existing provider MFA policy. The application namespace requires narrowly scoped HTTPS egress to the issuer; its existing policy only allows database traffic and DNS.

NetKingdom's password setup maps tenant:trial:demo-company to the fixed HTTPS company entry in PASSWORD_SETUP_TENANT_RETURNS. That return is stored inside the setup grant at issuance and released only after successful consumption. There is no browser-supplied return address, recipient credential transfer, automatic product login or modification to the operator's portal session. Existing setup grants have no new destination; issue a fresh link if needed.

Release and acceptance

Run application tests, assets build and migration drift checks, publish the exact source, and pin its digest in the existing Railiance pilot values. Migration 0003 adds only the unique identity mapping table. Keep the accepted 60m CPU / 256Mi memory request and both data claims. Disabling NETKINGDOM_ENABLED restores the interim local login; OIDC-created users still have unusable local passwords, so rollback does not manufacture credentials. Keep the added table when reverting an application image.

KeyCape's current main also contains previously accepted startup and token issuance changes after deployed source dcebd46; validate the live registration configuration before upgrading (key-cape/docs/operations.md). Existing login attempts are process-local and are lost on its single-replica Recreate rollout. Password-setup links are likewise process-local and expire on provisioner restart.

Native acceptance still requires the actual invited user to complete setup, fresh sign-in and any provider-required MFA, confirm their account, and enter the company workflow. Do not substitute an operator session. Recovery and two-user workflow acceptance remain the existing RAPPS-WP-0014-T03 and VERGABE-WP-0019-T04 tasks.