Worum es geht
Die meisten Rollen gehören einem Modul und gelten in einem Mandanten. Ein paar Rollen tun das nicht: Sie gelten überall und werden von der Plattform selbst geprüft, nicht von einem Modul. Das sind die Realm-Rollen der Plattform. In Keycloak liegen sie auf Realm-Ebene, im Token unter realm_access.roles.
Die sechs Rollen im Überblick
| Rolle | Wofür | Wer prüft sie | Im Rollenkatalog | Vergeben durch |
|---|---|---|---|---|
platform-admin | verwaltet die Plattform: alle Mandanten, alle Benutzer, den Katalog | CIAS bei jeder Verwaltungsoperation | ja, PLATFORM, Delegation leer | nur ein Plattform-Administrator |
user | jede Person mit Konto; der Boden, kein Recht | – | ja, PLATFORM | Plattform-Administrator; Registrierungen ohne Mandant vergeben sie als Startrolle |
mail-template-admin | den Wortlaut aller Mails ändern: die Standardfassungen und die jedes Mandanten | CIAS beim Bearbeiten von Mailvorlagen | ja, PLATFORM | Plattform-Administrator |
allowed-tenant-context-switch | in einen fremden Mandanten wechseln | Filterkette beim Header tenant | nein | direkt in Keycloak |
allowed-user-context-switch | im Namen einer anderen Person arbeiten, die das freigegeben hat | Filterkette beim Header user | nein | direkt in Keycloak |
declaration-reader | die Deklaration eines Moduls lesen, GET /cias/fetch | das Modul, etwa CDMS | nein | direkt in Keycloak, an das Konto, mit dem CIAS liest |
Die Rollen im Einzelnen
Wann: Jemand muss Mandanten anlegen, Rollen definieren, Benutzer verwalten.
Welche Rollen als Plattform-Administrator zählen, legt die Installation im Code fest, nicht in einer Einstellung mit Standardwert. Im eigenständigen CIAS ist das platform-admin. Ein Plattform-Administrator darf jede Rolle vergeben und erfüllt jede Obergrenze. Die Rolle selbst wird nie delegiert: Ihre Delegationsliste ist leer, also vergibt sie nur ein anderer Plattform-Administrator.
Ergebnis: Die erste Person bekommt sie beim ersten Start, wenn die Installation das so einstellt, siehe unten.
Wann: Jede Person mit Konto.
Kein eigentliches Recht, sondern der Boden. Die Installation nennt sie als Realm-Rolle, die beim Start angelegt wird. Eine Registrierung ohne Mandant vergibt sie als Startrolle.
Ergebnis: Im Katalog als Plattformrolle, vergebbar durch platform-admin.
Wann: Jemand soll die Texte der Mails pflegen, ohne die Plattform zu verwalten.
Wer diese Rolle hat, bearbeitet jede Mailvorlage: die Standardfassung jeder Mail und die Fassung jedes Mandanten. Welche Rollen das dürfen, stellt die Installation über CIAS_NOTIFICATION_EDITOR_ROLES ein; Standard ist platform-admin und mail-template-admin. Weil die Rolle die Texte aller Mandanten erreicht, ist sie eine Realm-Rolle und wird nie innerhalb eines Mandanten vergeben.
Ergebnis: Siehe Mailvorlagen bearbeiten.
Wann: Der Support soll in einen Mandanten schauen, in dem er nicht Mitglied ist.
Die Filterkette erlaubt den privilegierten Wechsel per Header tenant nur mit dieser Rolle, und nur in Mandanten aus der Liste der erlaubten Mandanten. Sie steht in keinem Katalog und wird nicht über CIAS vergeben.
Ergebnis: Siehe Zwischen Mandanten wechseln.
Wann: Der Support soll sehen, was eine bestimmte Person sieht.
Die Filterkette übernimmt den Header user nur mit dieser Rolle. Ohne sie wird eine Anfrage mit dem Header abgelehnt, 403 cias.authentication.user-switch-denied. Die Rolle allein reicht aber nicht: Die Zielperson muss den Wechsel freigegeben haben, sonst 403 cias.authentication.user-switch-not-consented. Wer die Rolle hat, darf außerdem eine Freigabe beantragen. Die Rolle steht in keinem Katalog und wird nicht über CIAS vergeben.
Ergebnis: Siehe Benutzerwechsel per Header.
Wann: CIAS liest die Deklaration eines Moduls, das als eigener Dienst läuft.
Das Modul beantwortet GET /cias/fetch nur für Tokens mit einer seiner Leserollen. In CDMS steht die Liste in codamai.cdms.cias.reader-roles, im generierten Projekt mit declaration-reader. Eine leere Liste heißt: niemand.
Ergebnis: Siehe Module melden ihre Rollen an.
Warum die Wechselrollen Realm-Rollen sind
Die beiden Wechselrollen müssen der Person überall folgen. Hinge allowed-tenant-context-switch an einem Mandanten, könnte die Person einmal wechseln, stünde dann im Ziel-Mandanten ohne die Rolle und käme nicht mehr zurück. Und eine Organisation, die solche Rollen vergeben könnte, würde ihren Administratoren den Zugang zu fremden Mandanten öffnen.
Woher Realm-Rollen kommen
-
1CIAS→Keycloaklegt die Realm-Rollen an, die die Installation unter
startup.realm-rolesnennt, etwauser -
2CIASträgt die Plattformrollen aus der Bootstrap-Konfiguration in den Katalog ein, im eigenständigen CIAS
platform-admin,userundmail-template-admin, ohne Eigentümer-Modul -
3CIAS→Keycloakgibt dem Konto mit der konfigurierten Adresse die Plattform-Administrator-Rolle, falls eingestelltErgebnis: Die Installation hat einen ersten Plattform-Administrator
Das Konto für den ersten Plattform-Administrator muss es in Keycloak schon geben. CIAS legt keine Konten mit Passwort an. Nennt die Konfiguration eine Adresse ohne Konto, startet die Anwendung nicht, statt das still zu überspringen.
Weil die Plattformrollen keinem Modul gehören, legt kein Abgleich sie je still.
Nicht verwechseln: die Rollen von CIAS als Modul
tenant-admin, tenant-owner und tenant-user klingen nach Plattform, sind aber Mandantenrollen. CIAS meldet sie an wie jedes andere Modul, sie liegen auf dem Client von CIAS und gelten in einem Mandanten.
| Rolle | Bedeutung | Im eigenständigen CIAS vergebbar durch |
|---|---|---|
tenant-admin | verwaltet einen Mandanten | tenant-owner, platform-admin |
tenant-owner | hat den Mandanten gegründet | platform-admin |
tenant-user | Mitglied eines Mandanten | tenant-admin, platform-admin |
Weitere Administratoren ernennt also die Eigentümerin des Mandanten, nicht jeder Administrator. Eine weitere Eigentümerin kann nur ein Plattform-Administrator ernennen.