PatinaDB Console

The console groups Query and Explore, temporal views (History, Anamnesis and Live changes), and administrator tools. Graph exploration supports node inspection, manual layout, zoom and Fit graph. Relationship labels appear around a focused node; History provides Engram details and historical queries.

In server mode with administrator credentials, Admin overview reports cluster membership, query activity, storage and cache metrics. Voting membership is separate from leader/follower role; learners do not vote. Region badges appear when the status response supplies a region.

License & telemetry reports the connected node’s loaded license, exact UTC expiry, remaining days, signed feature flags and effective entitlements. Feature entitlement does not imply that the corresponding runtime feature is configured. Telemetry’s configured state is shown separately from permission to opt out. No license token, customer identity or license path is exposed. Older servers without the reporting endpoint show unavailable information. This is not a cluster-wide license audit.

DB Archaeology combines Oxidation’s UTC activity mosaic with scrollable database Engram timelines. Selecting a day synchronizes both views. Collection samples at most the latest 500 Engrams per database, uses bounded request deadlines, and reports partial errors. Missing history is not proof of zero activity; the view is not a complete historical census or a graph-mutation counter.

The console’s read-only /admin/license and /admin/archaeology routes require server mode and administrator access. The upstream /mgmt/license endpoint is protected by the server’s operator authorization. Homepage images use synthetic demo data; they do not represent a live cluster or production telemetry.

Identity & Access and operator sessions

The Identity & Access view shows the signed-in operator’s effective access. Global administrators can manage local users and service accounts, direct database roles, permission profiles, provider bindings and subject blocks. External principals and provisioned groups are inspected read-only; their lifecycle stays with the identity provider. Lists are paginated, edits carry revision preconditions, and save conflicts require a reload. Nested permission and provider settings use labeled JSON fields. The preview explains the server’s effective-access decision; it does not replace authorization on subsequent requests.

Basic local accounts and database roles remain Community functionality. Fine-grained access expansion requires the applicable RBAC capability; external identity integration requires IAM. The server evaluates each mutation, including whether it reduces or expands access. Emergency disable and revocation controls remain accessible in the UI. Removing a subject block can expand access and is not an unconditional revocation operation. Real Entra, Okta and Keycloak deployments are not yet qualified by the automated mock-provider tests.

For multiple operators, start the Console in REST server mode with --sessions. Do not supply a shared --user or --password. Every operator’s credentials stay in Console process memory, and each session and refreshed credential generation uses its own upstream connection pool. The browser receives an opaque HttpOnly cookie, not an API or refresh token. Embedded and Bolt-only modes do not support this session model and show an explicit unsupported-mode explanation.

Server mode uses the single database configured by --database for Console queries. To use another database as the Console’s default, run a separately configured Console process; one Console session does not select a different database per user.

Hosted deployments require an HTTPS public origin (--public-origin) when the listen address is not loopback. Serve the Console behind an HTTPS reverse proxy; --listen itself does not enable TLS. The upstream REST server must use HTTPS unless it is loopback HTTP. --insecure-dev-cookies is restricted to loopback listen addresses and loopback public origins, even when that origin uses HTTPS.

The session defaults are 30 minutes idle, 12 hours absolute lifetime and five minutes of recent authentication. Configure these with --session-idle-secs (default 1800), --session-absolute-secs (43200) and --session-recent-auth-secs (300). Values must be positive; idle and recent-auth windows cannot exceed the absolute lifetime. The bounded store holds at most 10,000 sessions; least recently seen entries are evicted when needed. Authentication network operations share a nonwaiting limit of 32; saturation returns 503.

Every protected request re-verifies the upstream identity and effective access; logout removes the session without requiring a network check. Password reset, suspension, credential revocation and identity replacement end retained sessions at the next request. A changed effective-access fingerprint, including database roles, grants and strictness modes, retires the old session ID and requires a fresh login with a new ID. Individual upstream operations still enforce current authority; the Console fingerprint is not a substitute for server authorization. Existing local accounts need their replicated stable principal IDs assigned by the v18 migration before Console login; missing IDs return identity_migration_pending rather than accepting a display name as identity.

The current candidate revalidates authorization at /changes delivery boundaries, including replay, live delivery, and resynchronization. Expiry, revocation, or an unavailable check terminates the stream with an SSE error and clears buffered events. Targeted expiry and revocation regressions passed in the source-bound local validation. This does not promise instantaneous cluster-wide revocation before a change is committed; PR CI verification remains.

The browser uses these same-origin routes:

• GET /auth/session reports authentication state and a per-session CSRF token.
• POST /auth/login accepts local credentials; successful login replaces the previous session. The UI also offers explicit local break-glass sign-in.
• POST /auth/logout removes the session. Logout does not revoke independently issued API tokens.
• GET /auth/oidc/start and /auth/oidc/callback implement organizational sign-in.
• /me/access forwards the operator’s own /iam/me response; /admin/iam/* forwards management requests with that operator’s authority.

State-changing requests carry x-patina-csrf; identity-management writes also require recent authentication. A break-glass indicator comes from the server’s explicit root identity, not from a global Admin role. Service API keys and SCIM credentials are displayed once; the UI does not persist them in browser storage. Session responses prohibit caching.

Organizational sign-in configuration

Configure --oidc-issuer, --oidc-client-id, --oidc-client-secret-file, --oidc-redirect-uri and, where needed, --oidc-scopes. The redirect must exactly match the public origin plus /auth/oidc/callback. The scope set must include openid and obtain an access token authorized for the Patina API. --oidc-algorithms defaults to RS256; supported explicit choices are RS256, PS256, ES256 and EdDSA. Algorithms are never selected from untrusted token claims alone.

Use --oidc-ca-file for an additional private-provider CA bundle and repeated --oidc-allowed-network values for explicitly trusted private CIDRs. Development HTTP IdPs additionally require --oidc-allow-insecure-http; metadata destinations remain refused. Every resolved address is checked and pinned, proxies and redirects are disabled, and TLS hostname validation remains enabled. Discovery and token endpoints must share the issuer’s origin. Separate-origin provider endpoints are currently unsupported. Provider network reads have a ten-second bound and bounded JSON/token sizes; errors do not expose token bodies or secrets.

Sign-in uses PKCE S256, nonce, browser-bound state and a short-lived HttpOnly SameSite=Lax callback cookie. Signed ID-token claims and the API’s authoritative issuer, subject and stable identity must agree. Fresh authentication time comes from the signed claim, not callback receipt. Refresh is serialized per session, requires a newly signed ID token, preserves the original authentication time and cannot restore a session removed during the request. Providers that omit an ID token on refresh fail closed; sign in again instead. This is a conservative compatibility boundary, not a claim that every OIDC provider configuration works.