Rollen- und Rechte Konzept

Anwendungsspezifische Rollen (Client Roles)

Nutzer können mehreren (logischen, organisatorischen) Gruppen zugewiesen werden, die Berechtigung in den Anwendungen ergeben sich aus der Konfiguration der "Clients" (eine spezifische Anwendung mit Authenfizierungs-Einstellungen, auch "Resource Server") in Keycloak. Mehrere Instanzen einer Anwendung können mit gleichen Rollen-Namen arbeiten, da jede Instanz ein eigener Client ist, was identische Konfiguration innerhalb der Anwendungs-Instanzen ermöglicht.

Perspektivische Gruppen und Rollen

Inhaltlich hier nur beispielhafte Zuordnungen, eine vollständige Übersicht findet sich im in der internen Projektdokumentation.

Nutzer	Gruppe Keycloak	Client: Rolle (Keycloak)
alle	/df	cadenza:analyst
nur Betriebsteam	/df/operations	cadenza:admin airflow:admin cadenza:analyst (geerbt)
alle MA eines Fachbereich	/df/{fachbereich} (einfach)	cadenza_{fachbereich}:creator cadenza:analyst (geerbt)
alle MA eines Fachbereich	/df/{fachbereich}-Cadenza-Analyst (falls Entscheidung zur Nutzung einer Anwendung im Quell IdP liegt)	cadenza_{fachbereich}:creator cadenza:analyst (geerbt)
extern via Brokering	/extern/{idp-name}/{fachbereich}	cadenza_{fachbereich}:creator
...	...

Zuweisung und Auswertung

Anwendungsrollen werden in Keycloak im jeweiligen Anwendungsclient definiert. Die Mitgliedschaft in einer Gruppe kann nun als Rollen-Zuweisung in den jeweiligen Anwendungen interpretiert werden.

Dieselbe Gruppe (unten z.B. /fachbereich-x) führt zu unterschiedlichen Rollen in verschiedenen Anwendungen.

Mapping föderierter Gruppen

Gruppen, die aus externen Identity Providern (IdP) stammen, stehen nicht direkt zur Auswertung für Client-Rollen zur Verfügung. Um das Gruppen-zu-Client-Rollen-Mapping auch für föderierte Gruppen zu ermöglichen, ist eine zusätzliche Konfiguration erforderlich. Diese kann über Identity Provider Mapper vorgenommen werden (anzulegen unter Identity Providers -> Mappers ).

Variante 1: IdP Mapper "Advanced Claim to Group" (empfohlen)

Nutzen werden über diesen Mapper explizit existierenden Gruppen im Projekt-Keycloak zugeordnet, falls sie eine spezifische Ursprungs-Gruppe (oder andere Claims) besitzen.

Pro Ursprungs-Gruppe ist ein Mapper notwendig. Die Ziel-Gruppen sollten ein dezidiertes Segment haben, z.B. /extern/{idp-name}/{gruppe}, um externe Nutzer unabhängig von internen Nutzern berechtigen zu können.

Es ist von Vorteil, als Sync-Mode force zu nutzen, um Änderungen in Quell-Gruppen zu übernehmen.

Vorteil ist hier, dass nach wie vor eine Gruppe mehreren Rollen zugeordnet werden kann. Zudem werden Rollen nach wie vor gegen im Projekt-Keycloak vorhandene Rollen abgeglichen und zentral konfiguriert. Nachteil ist, dass eine zweistufige Zuordnung statt findet (Ursprungs-Gruppe gegen Ziel-Gruppe, Ziel-Gruppe gegen Client-Rollen)

Die Einrichtung erfolgt als "Advanced Claim to Group" Mapper im Kontext des jeweiligen Identity Providers:

• Name: beispielgruppe (Name der zu mappenden Gruppe für Nachvollziehbarkeit)
• Sync Mode Override: Force (für dauerhafte Synchronisation)
• Claims
• Key: groups
• Value: beispielgruppe (Name der Gruppe so wie im Quell IdP vorhanden)
• Group: beispielgruppe (Zielgruppe - vorher unter /extern/{idp-name}/{gruppe} anzulegen)

Die Zielgruppe kann dann normal mit Client-Rollen Zuweisungen belegt werden.

Variante 2: IdP Mapper "Claim to Role"

Nutzer werden über diesen Mapper anhand ihrer Ursprungs-Gruppe explizit Client-Rollen zugeordnet. Zwar ist die Zuordnung explizit, jedoch nicht mehr ausschliesslich im Client zentral konfiguriert. Damit gibt es zwei Stellen Anwendungs-Berechtigungen zu vergeben, wovon wir abraten.

Vorteile

• Anwendungsspezifische Rollen: Jede Anwendung definiert ihre eigenen Rollen
• Bessere Separation of Concerns: Klare Trennung zwischen Anwendungslogik und Rechteverwaltung
• Flexibilität: Dieselbe Gruppe kann in verschiedenen Anwendungen unterschiedliche Rollen auslösen
• Rollenvererbung: Rollen können über Gruppenhierarchien vererbt werden, wodurch Untergruppen automatisch die Berechtigungen der übergeordneten Gruppen übernehmen
• Granulare Kontrolle: Feingranulare Rechtevergabe pro Anwendung möglich
• Skalierbarkeit: Neue Anwendungen können unabhängig ihre Rollen definieren, Berechtigungen sind gebündelt zuweisbar (eine Rolle = mehrere Anwendungen)
• Optimierte Token-Größe: Nur relevante Rollen für die jeweilige Anwendung im Token
• Role Mapping: Möglichkeit, Gruppen auf verschiedene Client-Rollen zu mappen
• Best Practice: Entspricht Keycloak-Best-Practices für Multi-Tenant-Szenarien
• Mapping von föderierten Gruppen: Föderierte Gruppen können über Identity Provider Mapper auf Client-Rollen gemappt werden. Dies erfordert jedoch entsprechende Konfiguration im Identity Provider und ggf. Custom Mapper.

Nachteile

• Höhere Komplexität: Zusätzliche Konfigurationsebene (Client Roles + Group-to-Role Mapping)
• Mehraufwand bei Einrichtung: Jede Anwendung muss ihre Rollen definieren und Mappings konfigurieren
• Wartungsaufwand: Änderungen an Rollen müssen pro Client gepflegt werden
• Lernkurve: Team muss sich mit Client-Rollen-Konzept vertraut machen
• Migrationsaufwand: Bestehende Anwendungen müssen angepasst werden
• Potenzielle Inkonsistenzen: Risiko unterschiedlicher Rollendefinitionen über Anwendungen hinweg
• Debugging-Komplexität: Fehlersuche bei Berechtigungsproblemen wird aufwendiger