Keycloak
Zentrales Identity- und Access-Management der UDSP.
Keycloak ist ein Open-Source-System für Identity und Access Management. Es verwaltet Identitäten in voneinander getrennten Realms, bindet Anwendungen als Clients an und stellt standardisierte Anmelde- und Tokenendpunkte bereit. Benutzer, Gruppen, Rollen und Sitzungen werden zentral verwaltet; Anwendungen verwenden dafür insbesondere OpenID Connect und OAuth 2.0.
Zu den grundlegenden Konzepten gehören:
- Realms bilden voneinander getrennte Verwaltungs- und Identitätsbereiche.
- Clients repräsentieren Anwendungen, Oberflächen oder APIs, die Keycloak zur Anmeldung oder Tokenprüfung verwenden.
- Benutzer und Gruppen organisieren Identitäten und wiederkehrende Rollenzuweisungen.
- Client-Rollen und Realm-Rollen beschreiben Berechtigungen innerhalb einer Anwendung oder übergreifend im Realm.
- Scopes und Protocol Mapper bestimmen, welche freigegebenen Informationen und Berechtigungen ein Token enthält.
- Sessions und Token ermöglichen Single Sign-on und zeitlich begrenzte Zugriffe, ohne Passwörter an die Zielanwendung weiterzugeben.
Keycloak in der UDSP
Keycloak bildet den gemeinsamen Identitätsdienst der UDSP. Die Plattform betreibt eine zentrale Keycloak-Laufzeit und legt für jeden Mandanten einen eigenen Realm an. Dadurch bleiben Benutzer, Gruppen, Clients und Rollenzuweisungen mandantenbezogen getrennt, obwohl alle Realms technisch von derselben Plattformkomponente bereitgestellt werden.
Oberflächen wie HYPERSENSUS, Grafana, Superset, CKAN, Node-RED oder pgAdmin erhalten jeweils einen eigenen Client. Fach-APIs verwenden zusätzlich den Client api-access: Dessen Token können Datenraumzugehörigkeiten sowie die Scopes api:read, api:write und api:delete enthalten. APISIX prüft diese Token am veröffentlichten API-Zugang; die Zielkomponente bleibt für ihre fachlichen Regeln verantwortlich.
Die Keycloak-Laufzeit und ihre PostgreSQL-Datenbank werden durch den Keycloak- beziehungsweise PostgreSQL-Operator in Kubernetes verwaltet. Die Operatoren erzeugen jedoch keine fachlichen Clients und Rollen. Diese legt die UDSP-Automatisierung anschließend über die Keycloak Admin API aus dem Inventory an.
Technische Abhängigkeiten
Keycloak wird als gemeinsame Plattformkomponente betrieben. Laufzeit und Identitätsdaten bleiben dabei in einem eigenen, operatorverwalteten Stack.
PostgreSQL
Speichert Realms, Benutzer, Gruppen, Clients, Rollen und Sitzungszustände der zentralen Keycloak-Instanz.
Komponente öffnenKeycloak Operator
Erzeugt und aktualisiert die Keycloak-Laufzeit aus der deklarativen Kubernetes-Ressource.
Bereitstellung durch den Keycloak Operator
Ansible installiert den Operator und übergibt ihm die Laufzeitkonfiguration. Realms, Clients, Rollen und Benutzergruppen werden danach getrennt über die Keycloak Admin API angelegt; sie sind nicht Bestandteil der Operator-Reconciliation.
Konfiguration und Deployment
Die gemeinsame Keycloak-Instanz wird über inv_op_stack.keycloak_operator und inv_idm konfiguriert. Dazu gehören Operator und Namespaces, das initiale Administrationskonto, Realm- und Theme-Einstellungen, Ereignisprotokollierung, Replikate sowie das optionale logische Backup der Keycloak-Datenbank.
Die globalen Felder sind unter Plattformbasis konfigurieren: Identität, Verfügbarkeit und HYPERSENSUS dokumentiert. Ein Mandanten-Realm wird anschließend über idm.enable in dessen Inventory-Block aufgenommen.
Rollen und Rechte
Für den Zugriff auf geschützte Fach-APIs legt die UDSP am Client api-access drei Rollen an. Ihre Freigaben werden auf die API-Scopes abgebildet, die APISIX an den jeweiligen Routen prüft:
dataConsumer
Lesender Zugriff. Die Rolle wird dem Scope api:read zugeordnet.
dataProducer
Lesender und schreibender Zugriff über die Scopes api:read und api:write.
dataAdmin
Lesen, Schreiben und Löschen über api:read, api:write und api:delete.
Die Rollen gelten nur für den api-access-Client. Jede Oberfläche kann daneben eigene Client-Rollen besitzen – beispielsweise admin und viewer bei Node-RED oder die Standardrollen einer Analyseanwendung. Eine Rollenzuweisung wird deshalb immer am zuständigen Client und im richtigen Mandanten-Realm vorgenommen.
Das initiale Masterkonto aus inv_idm.platform ist ein technischer Plattformzugang mit weitreichenden Verwaltungsrechten. Es dient nicht als reguläre Fachidentität. Administrative Konten, Client-Secrets und Service-Account-Rechte müssen getrennt von normalen Nutzerrollen behandelt und auf den benötigten Umfang begrenzt werden.