UDSP · Identität und Zugriff

Rollen und Berechtigungen zentral steuern

Die UDSP bündelt Identitäten und Rollen in Keycloak. Das Rollenmodell verbindet globale Aufgaben, fachliche Datenräume und bei Bedarf organisationsgebundene Zugriffe.

Das Berechtigungskonzept der UDSP folgt dem Prinzip der rollenbasierten Zugriffskontrolle (Role-Based Access Control, RBAC): Ein Nutzer erhält niemals ein Recht einzeln, sondern ausschließlich über eine oder mehrere Rollen. Eine Rolle ist ein benanntes Bündel von Rechten. Dieses Grundprinzip gilt einheitlich für alle im Folgenden beschriebenen Bereiche.

Grundbegriffe im Überblick

Begriff	Bedeutung
Benutzer	Jede Person, die sich an der Plattform anmeldet.
Recht	Die kleinste Einheit einer Berechtigung, z. B. "Nutzerverwaltung bearbeiten" oder "Datenraum X lesen".
Rolle	Ein benanntes Bündel von Rechten, z. B. "Parkraum-Bearbeiter". Die einzige Möglichkeit, wie ein Nutzer Rechte erhält.
Gruppe	Eine Sammlung von Rollen, mit der mehrere Nutzer auf einmal ausgestattet werden können.
Datenraum	Ein technisch getrennter Datenbereich (z. B. "Park-Api"), auf den über Rollen zugegriffen wird.
Organisation	Eine optionale zusätzliche Ebene, z. B. eine Kommune, für die Rollen individuell vergeben werden.

Die Berechtigungsebenen im Überblick

Rollen können auf drei Ebenen vergeben werden, die aufeinander aufbauen, aber jeweils auch für sich allein funktionieren:

Ebene	Wofür gedacht	Beispiel
Global	Rechte, die unabhängig von einer Kommune oder Organisation gelten – der Standardfall	Nutzeradministration, Grafana-Zugriff
Datenraum	Zugriff auf einen technisch getrennten Datenbereich	Lesezugriff auf den Datenraum "Parkraumsensorik"
Organisationsspezifisch	Zusätzliche Ebene für Mandanten, die intern noch einmal unterteilt sind (z. B. mehrere Kommunen)	Parkraum-Betrachter für Bad Orb, Parkraum-Bearbeiter für Hanau

Die globale Ebene ist der Grundfall und für sich allein bereits vollständig funktionsfähig. Datenraum- und Organisationsebene kommen dort hinzu, wo sie fachlich gebraucht werden – ein Mandant, der keine interne Struktur wie Kommunen hat, benötigt die Organisationsebene schlicht nicht.

Berechtigungsprinzipien

Unabhängig davon, auf welcher Ebene (global, Datenraum oder Organisation) eine Berechtigung angesiedelt ist, gelten für die Vergabe folgende grundsätzlichen Prinzipien:

• Granulare Vergabe je Ebene: Berechtigungen werden nicht pauschal, sondern granular auf der jeweils passenden Ebene vergeben – global, datenraumspezifisch oder organisationsspezifisch, je nachdem, wie die zugrunde liegenden Rechte definiert sind (siehe Abschnitte 4–6). Eine Rolle kann dabei Rechte aus mehreren dieser Ebenen bündeln.
• Prinzip der minimalen Rechte (Least Privilege): Nutzer erhalten grundsätzlich nur die Rechte, die für ihre jeweilige Aufgabe tatsächlich notwendig sind. Rollen sollten entsprechend eng geschnitten und auf den konkreten Bedarf zugeschnitten werden, statt vorsorglich möglichst viele Rechte zu bündeln.
• Tokenbasierte Weitergabe: Berechtigungen werden nicht bei jedem einzelnen Zugriff neu ermittelt, sondern als Bestandteil eines Tokens über die gesamte Anfragekette hinweg weitergegeben – von der Anmeldung über die aufrufende Anwendung bis zu den beteiligten Backend-Diensten.
• Einheitliche Steuerung über zentrale Identitäten: API-Zugriffe und UI-Zugriffe werden einheitlich über dieselben zentralen Identitäten und Rollen gesteuert. Es existieren keine getrennten Berechtigungsmodelle für Oberfläche und Schnittstelle.
• Rollenhierarchie (Super-Admin-Prinzip): Administratoren mit einer entsprechend übergeordneten Rolle können grundsätzlich jede Rolle einnehmen und damit jede Berechtigung nutzen – so ist sichergestellt, dass sich jede Berechtigung im Zweifel auch administrativ erreichen und kontrollieren lässt.

Globale Rechte, Rollen und Gruppen

Globale Rechte gelten mandantenweit - unabhängig davon, ob der Mandat in eine Organisationsstruktur unterteilt ist – zum Beispiel die Verwaltung von Nutzerkonten oder der Zugriff auf ein plattformweites Werkzeug wie Grafana.

Wie das funktioniert:

1. Eine Anwendung (z. B. eine App zur Parkraumüberwachung, oder Grafana) definiert globale Rechte, z. B. "Nutzerverwaltung lesen/schreiben" oder "Grafana Dashboards bearbeiten".
2. Aus diesen Rechten werden globale Rollen gebildet, z. B. Nutzeradmin oder Grafana-Editor.
3. Diese Rollen werden direkt an einen Nutzer vergeben.

Für den Nutzer wirkt sich das unmittelbar aus: Sobald ihm eine Rolle zugewiesen wird, erhält er sofort die darin enthaltenen Rechte – und verliert sie ebenso sofort wieder, wenn ihm die Rolle entzogen oder die Rolle selbst gelöscht wird. Werden nachträglich die in einer Rolle enthaltenen Rechte geändert, wirkt sich das ohne weiteres Zutun auf alle Nutzer aus, die diese Rolle bereits besitzen.

Eine Gruppe ist eine Sammlung mehrerer globaler Rollen. Sie dient dazu, Nutzern mit ähnlichem Aufgabenbereich schnell die passende Kombination an Rollen zuzuweisen, ohne jede Rolle einzeln vergeben zu müssen.

• Wird ein Nutzer einer Gruppe hinzugefügt, erhält er automatisch alle Rollen, die in dieser Gruppe hinterlegt sind.
• Ein Nutzer kann Mitglied mehrerer Gruppen gleichzeitig sein.
• Wird ein Nutzer aus einer Gruppe entfernt, oder wird die Gruppe gelöscht, verliert er alle Rollen (und damit Rechte), die er ausschließlich über diese Gruppe erhalten hat. Rollen, die ihm zuvor einzeln und direkt zugewiesen wurden, bleiben davon unberührt.
• Wird einer Gruppe eine Rolle hinzugefügt oder aus ihr entfernt, wirkt sich das automatisch auf alle aktuellen und künftigen Mitglieder aus: Sie erhalten die Rolle (und die zugehörigen Rechte) automatisch, sobald sie Mitglied werden bzw. sobald die Rolle ergänzt wird – ohne dass jedes Mitglied einzeln bearbeitet werden muss.

User und Gruppe führen beide (n:m) zur Rolle – direkt oder über die Gruppenmitgliedschaft. Die Rolle bündelt ihrerseits beliebig viele Rechte (n:m), die von einer Anwendung definiert werden (1:n).

Technische Umsetzung

Pro Mandant verwaltet die UDSP einen Keycloak-Realm mit den Clients der bereitgestellten Anwendungen. Globale Rollen werden als Client-Rollen geführt und entweder direkt einem Benutzer oder einer Keycloak-Gruppe zugeordnet. Der aktuelle Plattformadministrator erhält beim Rollout die dafür vorgesehenen administrativen Client-Rollen.

Für die geschützten Fach-APIs stellt der Client api-access die Rollen dataConsumer, dataProducer und dataAdmin bereit. Daraus werden die Scopes für lesende, schreibende und löschende Aufrufe abgeleitet. Details zu dieser Gateway-Prüfung stehen unter Authentifizierung und API-Zugriff.

Datenraum-Berechtigungen

Ein Datenraum ist ein technisch vollständig getrennter Datenbereich (z. B. "Parkraumsensorik"), der bestimmte Datensätze enthält. Für jeden Datenraum gibt es einzelne Rechte für die jeweiligen Zugriffsarten – typischerweise Lesen, Schreiben, Anlegen und Löschen.

Wichtig: Wie bei der globalen Ebene gilt auch hier: Ein Nutzer erhält Zugriff auf einen Datenraum ausschließlich über eine Rolle, nie als direkte Einzelzuweisung. Eine Rolle kann dabei die Rechte für einen oder mehrere Datenräume bündeln, zusätzlich zu ihren übrigen globalen Rechten.

Beispiel: Eine Rolle "Parkraumsensorik-Bearbeiter" bündelt die Rechte "Parkraumsensorik lesen", "Parkraumsensorik anlegen" und "Parkraumsensorik bearbeiten". Ein Nutzer, der diese Rolle erhält (direkt oder über eine Gruppe), kann auf die Datensätze im Datenraum Parkraumsensorik entsprechend zugreifen.

Auch hier gilt die allgemeine Wirkung von Rollenänderungen aus Abschnitt 4: Wird einem Nutzer die Rolle entzogen, die Rolle gelöscht oder werden ihr die Datenraum-Rechte entzogen, verliert er unmittelbar den entsprechenden Zugriff auf den Datenraum.

Ein Datenraum definiert seine Rechte (1:n). Eine Rolle bündelt beliebig viele dieser Rechte (n:m) und wird direkt an User vergeben (n:m) – ohne Möglichkeit einer direkten Einzelzuweisung an den Datenraum.

Technische Umsetzung

Die Plattform übergibt Datenraumzuordnungen für den NGSI-LD-Zugang als tenants-Claim im Access Token. APISIX vergleicht den angeforderten Datenraum mit diesem Claim, bevor eine Anfrage Stellio erreicht. Andere Komponenten nutzen ihre eigenen fachlichen Modelle, etwa Workspaces in GeoServer oder organisationsbezogene Rollen in CKAN. Die konkrete Zuordnung ist deshalb auf den jeweiligen Komponentenseiten beschrieben.

Organisationsspezifische Rechte und Rollen

Bei manchen Mandanten reicht die globale Ebene nicht aus, weil der Mandant selbst noch einmal in mehrere Einheiten unterteilt ist – zum Beispiel ein Landkreis, der aus mehreren Kommunen besteht. Für diesen Fall gibt es eine zusätzliche, optionale Organisationsebene: Statt eine Rolle pauschal an einen Nutzer zu vergeben, wird sie an die Kombination aus Nutzer und Organisation (z. B. einer einzelnen Kommune) geknüpft.

Die Organisationsebene ist über ein Flag abschaltbar. Ist sie deaktiviert, greift von diesem Abschnitt nichts: Es gibt keine Organisationen, jede Rolle wirkt global und wird direkt an Nutzer vergeben. Das ist der Regelfall für Mandanten ohne interne Untergliederung. Alles Weitere in diesem Abschnitt beschreibt ausschließlich den aktivierten Zustand.

Wie das funktioniert:

1. Eine Anwendung (z. B. eine App zur Parkraumüberwachung) definiert eine Reihe organisationsgebundener Rechte, z. B. "Parkverstoß melden" oder "Parkverstoß bearbeiten".
2. Aus diesen Rechten werden Rollen zusammengestellt, z. B. Parkraum-Bearbeiter und Parkraum-Betrachter.
3. Ein Administrator legt für jede Organisation fest, welche dieser Rollen dort überhaupt vergeben werden dürfen. Nicht jede Organisation muss zwangsläufig Zugriff auf alle Rollen einer Anwendung haben.
4. Ein Administrator weist einem Nutzer eine Rolle innerhalb einer bestimmten Organisation zu.

Beispiel: Ein Nutzer wird der Kommune Bad Orb mit der Rolle Parkraum-Betrachter zugeordnet und gleichzeitig der Kommune Hanau mit der Rolle Parkraum-Bearbeiter. Er hat also in Bad Orb weniger Rechte als in Hanau – die Rolle hängt immer an der Kombination aus Nutzer und Organisation, nicht am Nutzer allein.

Wird einer Organisation nachträglich die Zulässigkeit für eine Rolle entzogen, verlieren alle Nutzer, die diese Rolle bei dieser Organisation innehatten, unmittelbar den entsprechenden Zugriff – unabhängig davon, ob sie dieselbe Rolle bei einer anderen Organisation weiterhin besitzen.

Ein User erhält eine Rolle nie direkt, sondern ausschließlich im Kontext einer Organisation, der er zugeordnet ist. Die Organisation wiederum legt fest, welche Rollen bei ihr überhaupt zulässig sind (Whitelist). Die Rolle bündelt n:m Rechte, die von einer Anwendung definiert werden (1:n).

Technische Umsetzung

Technische Umsetzung mit Keycloak

Das Fachmodell wird vollständig in Keycloak abgebildet: ein einzelner Realm, der mehrere Anwendungen gemeinsam trägt.

Die Fachmodell-Relation USER_ORGANISATION_ROLLE existiert in Keycloak nicht als eigenes Objekt. Sie entsteht erst aus vier markierten Objekten: 1 Org-Subgroup und 2 Role-Subgroup ergeben über die Elternkette die Organisation, 3 das Group-Role-Mapping den Verweis auf die Rolle, 4 die Gruppenmitgliedschaft den Benutzer.

Fachmodell	Abbildung in Keycloak
Anwendung	Client; die client_id erscheint im Token-Claim
Organisation	Org-Group, also eine Gruppe ohne Elterngruppe
Whitelist: welche Rolle ist bei welcher Organisation zulässig	Existenz der Gruppenkette /<kommune>/<anwendung>/<rolle> samt Role-Mapping
Zuweisung, organisationsgebunden	Gruppenmitgliedschaft in dieser Role-Subgroup
Zuweisung, global	direktes User-Role-Mapping

Recht und Rolle sind dieselbe Objektart: beides sind Client Roles. Unterschieden werden sie über zwei Role Attributes – frei gesetzte Schlüssel-Wert-Paare, keine festen Felder:

Attribut	Wert	Bedeutung
typ	recht	Kleinste Berechtigungseinheit; wird nur gebündelt, nie zugewiesen
typ	rolle	Bündel von Rechten und die einzige zuweisbare Einheit
bindungstyp	organisation	Wirkt nur innerhalb einer Kommune; Vergabe über Gruppenmitgliedschaft
bindungstyp	global	Wirkt organisationsübergreifend; Vergabe über User-Role-Mapping

typ ist nötig, weil Keycloak eine Rolle erst als composite markiert, sobald sie ein Kind hat – eine leere Rolle wäre sonst von einem Recht nicht unterscheidbar. Namenskonvention: Rechte klein, Rollen groß – parkverstoss-bearbeiten gegenüber PARKRAUM-BEARBEITER. Da beide flach im selben Token-Claim stehen, ist die Schreibweise dort das einzige Unterscheidungsmerkmal.

Durchsetzung der Typtrennung

Alle Ebenen liegen in Keycloak als gleichartige Objekte in einem Realm. Die Trennung hängt allein an typ, bindungstyp und der Struktur des Gruppenbaums und ist damit Konvention, kein Constraint: Keycloak prüft nichts davon und erzwingt nicht einmal, dass die Attribute gesetzt sind. Zu beachten ist außerdem, dass Keycloak Gruppen-Role-Mappings an alle Untergruppen vererbt.

Durchgesetzt wird das in der Administrationsschicht, und sie muss der einzige schreibende Zugang sein. Ergänzend sollte ein regelmäßiger Abgleich diese Invarianten prüfen:

#	Invariante (immer gültig)
I1	typ ist an jeder Client Role gesetzt; ein fehlender Wert gilt nicht als rolle
I2	Zugewiesen wird nur typ = rolle, ein Recht nie direkt
I3	Keine Verschachtelung: typ = recht bündelt nichts, typ = rolle ist nie Kind einer Rolle
I4	Namenskonvention: typ = recht klein, typ = rolle groß

#	Invariante (nur mit Organisationsebene)
I5	bindungstyp ist gesetzt; ein fehlender Wert gilt nicht als global
I6	organisation ⇒ kein direktes User-Role-Mapping
I7	organisation ⇒ mindestens eine Role-Subgroup mappt die Rolle, sonst ist sie nicht vergebbar
I8	global ⇒ keine Role-Subgroup mappt die Rolle
I9	global ⇒ alle gebündelten Rechte sind global. Umgekehrt ist Mischen erlaubt
I10	Jede Role-Subgroup mappt genau eine Rolle und trägt deren Namen
I11	Org-Group und Org-Subgroup tragen keine Role-Mappings
I12	Der Name der Org-Subgroup ist die client_id des Clients der gemappten Rolle

Ist die Organisationsebene deaktiviert, entfallen I5–I12: Jede Rolle wirkt global und wird direkt zugewiesen.

Organisationskontext im Token

Rollen aus einer Gruppenmitgliedschaft landen flach im Rollen-Claim – ohne Organisationsbezug. Für das Beispiel aus Abschnitt 6 (Betrachter in Bad Orb, Bearbeiter in Hanau) enthält der Token die Vereinigung aller Rechte, ohne dass erkennbar wäre, dass parkverstoss-bearbeiten nur für Hanau gilt:

{
  "resource_access": {
    "parkraum": {
      "roles": [
        "PARKRAUM-BETRACHTER", "parkverstoss-lesen",
        "PARKRAUM-BEARBEITER", "parkverstoss-melden", "parkverstoss-bearbeiten"
      ]
    }
  }
}

Das Tupel (user, organisation, rolle) ist ausschließlich über den Gruppenpfad rekonstruierbar. Daraus folgt:

1. Group-Membership-Mapper ist Pflicht. Jeder Client, der organisationsgebundene Rechte auswertet, braucht einen Protocol Mapper vom Typ Group Membership mit Claim-Name groups und aktivierter Option Full group path:

   { "groups": ["/bad-orb/parkraum/PARKRAUM-BETRACHTER", "/hanau/parkraum/PARKRAUM-BEARBEITER"] }

2. Autorisierungsentscheidungen erfolgen pfadbasiert, nicht rollenbasiert. Die auswertende Komponente ermittelt die Organisation aus dem Request und prüft sie gegen den groups-Claim; Rollen mit bindungstyp = organisation dürfen aus dem Rollen-Claim nicht herangezogen werden. Das schränkt das Prinzip der einheitlichen Steuerung (Abschnitt 3) ein und muss in jeder auswertenden Komponente implementiert sein.

Nachvollziehbarkeit und Grenzen

Änderungen an Rollen, Gruppen und organisationsbezogenen Zuweisungen müssen im jeweiligen Verwaltungsprozess nachvollziehbar dokumentiert werden. Das Rollenmodell ersetzt dabei keine fachliche Governance: Es beschreibt, wer eine technische Aktion ausführen darf. Welche Daten veröffentlicht, geändert oder weitergegeben werden dürfen, wird zusätzlich durch Datenverantwortung, Schnittstellenvertrag und die Regeln der zuständigen Komponente bestimmt.

Weiterführend:

• Keycloak als zentrale Identitätsverwaltung
• APISIX als Gateway für geschützte Fach-APIs
• Sicherheitsarchitektur für die weiteren Schutzebenen der Plattform