2026-05-22 20:55:27 +02:00
|
|
|
# Configuration Boundaries
|
|
|
|
|
|
|
|
|
|
## Standalone Mode
|
|
|
|
|
|
|
|
|
|
Standalone mode is for local development, tests, prototypes, and small
|
|
|
|
|
single-service deployments.
|
|
|
|
|
|
|
|
|
|
Expected characteristics:
|
|
|
|
|
|
|
|
|
|
- local configuration file or environment variables;
|
|
|
|
|
- local database or file-backed persistence during early development;
|
|
|
|
|
- fixture or local identity claims adapter;
|
|
|
|
|
- deterministic authorization test adapter;
|
|
|
|
|
- no password, MFA, or token issuance responsibility inside user-engine.
|
|
|
|
|
|
|
|
|
|
## Platform Mode
|
|
|
|
|
|
|
|
|
|
Platform mode is for a NetKingdom-aligned shared service deployment.
|
|
|
|
|
|
|
|
|
|
Expected characteristics:
|
|
|
|
|
|
|
|
|
|
- verified IAM Profile claims arrive from an identity layer;
|
|
|
|
|
- authorization decisions are requested through the authorization check port;
|
|
|
|
|
- runtime secrets are delivered through a scoped secret provider;
|
|
|
|
|
- audit records and outbox events are correlated with platform sinks;
|
|
|
|
|
- tenant and application bindings are explicit.
|
|
|
|
|
|
|
|
|
|
## Secret Names
|
|
|
|
|
|
|
|
|
|
The code should refer to logical secret names, not platform paths. Concrete
|
|
|
|
|
secret lookup is owned by the active `SecretProvider` adapter.
|
|
|
|
|
|
|
|
|
|
Initial logical names:
|
|
|
|
|
|
|
|
|
|
- `database.url`
|
|
|
|
|
- `event.signing_key`
|
|
|
|
|
- `webhook.shared_secret`
|
|
|
|
|
|
|
|
|
|
## Production Guardrails
|
|
|
|
|
|
|
|
|
|
- Local issuers must be rejected by production adapters.
|
|
|
|
|
- Sensitive writes must fail closed when authorization is unavailable.
|
|
|
|
|
- Claims enrichment must be optional and must not make user-engine a token
|
|
|
|
|
issuer.
|
2026-08-08 23:09:23 +02:00
|
|
|
|
|
|
|
|
## Portal integration settings
|
|
|
|
|
|
|
|
|
|
The production portal requires its existing database, OIDC, proxy-marker, and
|
|
|
|
|
identity-provisioning settings. Platform tenant creation is enabled only when
|
|
|
|
|
both of these settings are present:
|
|
|
|
|
|
|
|
|
|
- `USER_ENGINE_TENANT_MANAGEMENT_URL` — tenant-authority base URL;
|
|
|
|
|
- `USER_ENGINE_TENANT_MANAGEMENT_TOKEN` — workload-scoped bearer token.
|
|
|
|
|
|
|
|
|
|
The adapter calls `POST /v1/tenants` with correlation and idempotency headers.
|
|
|
|
|
The token is never returned in errors, audit records, outbox events, or browser
|
|
|
|
|
responses. When the settings are absent, ordinary portal behavior remains
|
|
|
|
|
available and platform tenant creation fails closed as unavailable.
|
