Identity Provider Login for Internal Services

The Core Platform Portal uses the independently deployed core-platform-auth Keycloak service for human sign-in, context selection, session refresh, and logout. Keycloak owns tenant UUIDs, short names and display names. After validating a token from the configured issuer and realm, the Portal uses its tenant UUID directly and creates an empty tenant record on first authenticated use. Adding a tenant to the applicable Auth realm and policy requires no API/UI allowlist change or tenant-specific migration. Invalid tokens and malformed claims fail closed. A user-facing Context combines the Portal instance and this tenant; internal identifiers, token claims and storage retain Tenant terminology.

Portal operators configure the UI with the canonical Portal URL, shared Auth.js secret, server-side signing key, Keycloak issuer, and portal client ID. The UI uses the fixed /auth Auth.js base path. The API validates the configured issuer and realm, the core-platform audience, and the authorized client (portal or corectl). Runtime and Control Agent credentials remain separate from human authentication; connected agents also send the immutable Keycloak tenant UUID supplied by their generated installation command.

Internal services such as:

Grafana
Platform Docs

Are exposed with Identity Provider login, currently only Google Gsuite is supported.

Configuring the domain for internal services

In your environment configuration


internal_services:
  name: secure
  domain: "gcp-dev-internal.cecg.platform.cecg.io"

The domain must be different from your ingress_domains.

DNS delegation for that domain should be configured as in DNS

Context names

The Auth policy mapping key supplies the short name, used in CLI contexts and context selectors. The display_name field supplies the human-readable label, exposed as displayName by the API and UI. Both names come from Keycloak token claims; the Portal database stores only tenant UUIDs and creation timestamps.

Changing a display name takes effect for new authentication sessions. Existing sessions and token refreshes may retain their earlier names. A display-name change does not alter tenant identity or CLI context names.