UDSP · Identität und Zugriff

Rollen und Berechtigungen in der UDSP

Keycloak verwaltet Identitäten, anwendungsspezifische Client-Rollen und Gruppen je Mandant. HYPERSENSUS und die Plattform-APIs verwenden davon getrennte, für ihren jeweiligen Zugriffspfad vorgesehene Zuordnungen.

In der UDSP gibt es kein übergreifendes fachliches Rollenmodell, das Berechtigungen verschiedener Anwendungen zu neuen Rollenbündeln zusammenfasst. Vorhandene Keycloak-Rollen werden Benutzern direkt am jeweiligen Client zugewiesen.

Das Modell im Überblick

Begriff	Bedeutung in der UDSP
Mandant	Getrennter Plattformbereich mit einem eigenen Keycloak-Realm.
Client	Repräsentiert eine Anwendung oder einen technischen Zugang innerhalb eines Realms.
Client-Rolle	Berechtigung für genau einen Client, beispielsweise admin am Client hypersensus oder dataConsumer am Client api-access.
Direkte Rollenzuweisung	Verknüpft einen Benutzer unmittelbar mit einer Realm- oder Client-Rolle in Keycloak.
HYPERSENSUS-Dataspace-Gruppe	Aus einem Datenbankschema abgeleitete Keycloak-Gruppe. Ihre Mitgliedschaft steuert in HYPERSENSUS die Sichtbarkeit der zugehörigen Tabellen.
API-Datenraumgruppe	Speziell markierte Keycloak-Gruppe, die beim geschützten Plattform-API-Zugang in den tenants-Claim übernommen wird.
Scope	Im Token freigegebener Zugriffsumfang für eine Plattform-API, beispielsweise api:read.

Die gleichartige technische Ablage in Keycloak bedeutet nicht, dass alle Rollen und Gruppen dieselbe Wirkung haben. Jeder Dienst wertet nur die für ihn vorgesehenen Client-Rollen, Claims oder Gruppenmitgliedschaften aus.

Trennung nach Mandanten und Anwendungen

Die UDSP betreibt eine gemeinsame Keycloak-Instanz und legt für jeden konfigurierten Mandanten einen eigenen Realm an. Benutzer, Gruppen, Clients und Rollenzuweisungen eines Mandanten bleiben dadurch von anderen Mandanten getrennt.

Innerhalb eines Realms erhält jede angebundene Anwendung ihren eigenen Client. Eine Client-Rolle gilt deshalb immer im Kontext dieser Anwendung. Die Rolle dataAdmin am Client api-access erteilt beispielsweise nicht automatisch Zugriff auf HYPERSENSUS, Node-RED, Grafana oder CKAN.

Benutzer- und Rollenverwaltung in HYPERSENSUS

HYPERSENSUS verwendet Keycloak als führendes System und verwaltet kein separates Rollenverzeichnis. Die Anwendung kann Benutzer anlegen und vorhandene Realm- und Client-Rollen aus Keycloak lesen. Beim Bearbeiten eines Benutzers werden Rollen direkt diesem Benutzer zugeordnet; es werden keine neuen fachlichen Rollen erzeugt und keine Client-Rollen zu einer übergreifenden Rolle gebündelt.

Die Oberfläche zeigt vorhandene Rollen nach Client getrennt an. Bearbeitbar sind dort nur Rollen des Clients hypersensus; Rollen anderer Anwendungsclients werden lediglich angezeigt. Für HYPERSENSUS sind die Client-Rollen admin und chatbot-access vorgesehen:

HYPERSENSUS-Rolle	Wirkung
admin	Administrativer Zugriff in HYPERSENSUS; administrative Prüfungen können dadurch erfüllt werden.
chatbot-access	Schaltet den Zugriff auf die Chatbot-Funktion frei.

HYPERSENSUS liest die Client-Rollen aus resource_access des Keycloak-Tokens und prüft feste, anwendungsspezifische Rollennamen. Für Grafana, MinIO, Superset und Node-RED sind ebenfalls eigene Client-Rollen vorgesehen. Höhere Rollen können innerhalb dieser festen Anwendungslogik niedrigere Zugriffsstufen einschließen; daraus entsteht jedoch kein frei konfigurierbares, plattformweites Rollenmodell.

Änderungen an einer Rollenzuweisung werden direkt in Keycloak vorgenommen und mit der nächsten Tokenausstellung beziehungsweise Tokenaktualisierung wirksam.

Dataspace-Zugriff in HYPERSENSUS

HYPERSENSUS leitet seine verfügbaren Dataspaces aus den vorhandenen Datenbankschemas ab. Für jedes Schema stellt es eine gleichnamige Keycloak-Gruppe sicher. Die Mitgliedschaft eines Benutzers in diesen Gruppen bestimmt, welche Tabellen HYPERSENSUS für ihn sichtbar macht.

Diese Gruppen gehören zum internen HYPERSENSUS-Zugriffsmodell. Sie sind nicht automatisch identisch mit den speziell markierten Datenraumgruppen des Plattform-API-Zugangs und erzeugen allein keinen tenants-Claim für APISIX.

Rollen und Scopes für geschützte Plattform-APIs

Der Client api-access stellt drei Client-Rollen bereit. Beim Anfordern eines Access Tokens entscheidet die Rollenzuordnung, welche API-Scopes aufgenommen werden dürfen:

Client-Rolle	api:read	api:write	api:delete
dataConsumer	✓	–	–
dataProducer	✓	✓	–
dataAdmin	✓	✓	✓

Die Scopes entsprechen den am Gateway veröffentlichten HTTP-Methoden:

• api:read erlaubt lesende GET-Aufrufe.
• api:write erlaubt POST, PUT und PATCH.
• api:delete erlaubt DELETE.

Ein Client kann sich durch den Parameter scope keine zusätzlichen Berechtigungen geben. Keycloak nimmt einen angeforderten Scope nur dann in das Token auf, wenn die Rollen des Benutzers ihn erlauben. APISIX vergleicht anschließend HTTP-Methode und Route mit den vorhandenen Scopes.

Datenraumzuordnung für den Plattform-API-Zugang

Für diesen Zugriffspfad werden Datenräume in Keycloak als speziell markierte Gruppen geführt. Eine solche Gruppe besitzt die Attribute service=true und tenant=true. Ist ein Benutzer Mitglied der Gruppe, ergänzt der UDSP-spezifische Protocol Mapper den Gruppennamen im tenants-Claim des Tokens.

Ein Token kann beispielsweise folgende Zugriffsinformationen enthalten:

{
  "scope": "openid api:read api:write",
  "tenants": [
    {"name": "default_dataspace"},
    {"name": "parkraumsensorik"}
  ]
}

Beim NGSI-LD-Zugang über Stellio enthält die Anfrage den gewünschten Datenraum im Header NGSILD-Tenant. APISIX erlaubt die Weiterleitung nur, wenn dieser Name im tenants-Claim enthalten ist. Fehlt der Header, verwendet die aktuelle Route default_dataspace; auch dieser Datenraum muss dem Benutzer zugeordnet sein.

Technischer Zugriffspfad der Plattform-APIs

1. Der Benutzer authentifiziert sich im Realm seines Mandanten.
2. Keycloak ermittelt die Rollen des Clients api-access und die speziell markierten API-Datenraumgruppen des Benutzers.
3. Das Access Token enthält die erlaubten Scopes und den tenants-Claim.
4. APISIX prüft Token, Route und HTTP-Methode. Für NGSI-LD prüft es zusätzlich den angeforderten Datenraum.
5. Erst nach erfolgreicher Prüfung wird die Anfrage an den zuständigen Fachdienst weitergeleitet.

Komponentenspezifische Berechtigungen

Die drei Rollen des Clients api-access schützen ausschließlich die über APISIX veröffentlichten Plattform-APIs. HYPERSENSUS, Grafana, MinIO, Superset, Node-RED und weitere Anwendungen besitzen daneben eigene Client-Rollen oder interne Berechtigungsmodelle.

Diese Modelle werden nicht automatisch ineinander übersetzt oder gemeinsam gebündelt. Insbesondere ersetzen API-Scopes weder CKAN-Berechtigungen noch MinIO-Zugangsschlüssel, GeoServer-interne Rollen oder anwendungsspezifische Administrationsrechte. Die konkrete Zuordnung ist auf den jeweiligen Komponentenseiten beschrieben.

Administration und Grenzen

Der Plattform-Rollout legt Realms, Clients, vorgesehene Rollen, Scope-Mappings, API-Datenraumgruppen und den initialen Administrationsbenutzer über die Keycloak Admin API an. HYPERSENSUS greift auf diese Keycloak-Strukturen zu und kann in seinem aktuellen Verwaltungsumfang Benutzer, eigene Client-Rollen-Zuweisungen und schemaabhängige Dataspace-Gruppen bearbeiten.

Das initiale Administrationskonto besitzt bewusst weitreichende Rechte und ist kein reguläres Fachkonto. Für weitere Konten gilt das Prinzip der minimalen Rechte: Es werden nur die Client-Rollen, Dataspaces und komponentenspezifischen Berechtigungen vergeben, die für die jeweilige Aufgabe benötigt werden.

Weiterführend:

• Keycloak als zentrale Identitätsverwaltung
• Authentifizierung und API-Zugriff für Tokenabruf und Gateway-Prüfung
• APISIX als Gateway für geschützte Plattform-APIs
• Sicherheitsarchitektur für die weiteren Schutzebenen der Plattform