Single Sign-On

All user-facing tools in this repository — kubectl, Headlamp, Argo CD, Grafana, Prometheus — delegate authentication to Keycloak, implementing [SE01 OpenID Connect Authentication] under the "OIDC only" constraint [CT-005 OpenID Connect only ]. Keycloak itself is organized as a small federation of realms, each with a distinct trust boundary and purpose, rather than a single flat realm holding every client and user.

Figure 1. Realm federation used for Single Sign-On.

Realm Purpose

Realm	Purpose
`master`	Keycloak’s built-in superuser realm. Reserved exclusively for Keycloak administrators managing the Keycloak instance itself (realms, clients, federation links). No application or end-user client is ever registered here, keeping the blast radius of a compromised admin account limited to Keycloak administration.
`kaiserpfalz-edv`	The organization’s identity-brokering realm. It federates external Identity Providers (e.g. social/enterprise IDPs) so that a person authenticates once against their external identity and that identity is then brokered into the realms below via Keycloak’s Identity Provider linking, instead of every application realm integrating external IDPs individually.
`k8s`	The technical realm for hosting/cluster access. It holds the OIDC clients used to log in to the infrastructure this repository operates — `kubectl`/Headlamp (`k8s-pandur`), Argo CD, Grafana, Prometheus — and the groups (e.g. `oidc:cluster-admin`) that RBAC in the cluster maps to. Its users are brokered in from `kaiserpfalz-edv` rather than being created directly.
`torg-codex`	Application realm for the Torg Codex system. Holds that application’s own clients, roles and group mappings, independent of the `k8s` realm’s RBAC groups.
`paladins-inn`	Application realm for the Paladins Inn system. Same purpose as `torg-codex`: an application-specific realm isolated from cluster access and from other applications.

master

Keycloak’s built-in superuser realm. Reserved exclusively for Keycloak administrators managing the Keycloak instance itself (realms, clients, federation links). No application or end-user client is ever registered here, keeping the blast radius of a compromised admin account limited to Keycloak administration.

kaiserpfalz-edv

The organization’s identity-brokering realm. It federates external Identity Providers (e.g. social/enterprise IDPs) so that a person authenticates once against their external identity and that identity is then brokered into the realms below via Keycloak’s Identity Provider linking, instead of every application realm integrating external IDPs individually.

k8s

The technical realm for hosting/cluster access. It holds the OIDC clients used to log in to the infrastructure this repository operates — kubectl/Headlamp (k8s-pandur), Argo CD, Grafana, Prometheus — and the groups (e.g. oidc:cluster-admin) that RBAC in the cluster maps to. Its users are brokered in from kaiserpfalz-edv rather than being created directly.

torg-codex

Application realm for the Torg Codex system. Holds that application’s own clients, roles and group mappings, independent of the k8s realm’s RBAC groups.

paladins-inn

Application realm for the Paladins Inn system. Same purpose as torg-codex: an application-specific realm isolated from cluster access and from other applications.

Rationale: Splitting realms this way keeps each trust boundary minimal: a master compromise is contained to Keycloak administration; external IDP integration work happens once in kaiserpfalz-edv instead of being duplicated per application; the k8s realm’s group-to-RBAC mapping (see OIDC Login) is not diluted by unrelated application roles; and torg-codex/paladins-inn can evolve their own roles and clients without risking accidental privilege overlap with cluster access.

See OIDC Login for the kubectl/Headlamp login flow against the k8s realm, and security for how the keycloak Helm release is deployed.