Worum es geht
Stell dir vor, jede neue Kollegin im Support braucht dieselben zehn Rollen, verteilt auf CDMS, CRMS und den Realm. Du könntest jede Rolle einzeln vergeben, bei jeder Person, und beim Ausscheiden jede einzeln wieder entziehen. Oder du legst einmal die Gruppe support an, gibst ihr die zehn Rollen und machst die Kollegin zum Mitglied.
Eine Gruppe ist also ein Bündel von Rollen mit Mitgliedern. Wer Mitglied ist, bekommt alle Rollen der Gruppe. Wer die Gruppe verlässt, verliert sie wieder.
Das Bild
flowchart LR
subgraph C["CIAS (führt die Gruppe)"]
direction TB
G["Gruppe support<br/>Name, Beschreibung<br/>Standardgruppe: nein"]
R["Rollen<br/>realm: user<br/>cdms-backend: customer-read, order-edit<br/>crms-backend: ticket-edit"]
M["Mitglieder<br/>Anna, Ben, Chris …"]
G --> R
G --> M
end
subgraph K["Keycloak (hält die Kopie)"]
KG["Gruppe support im Realm<br/>cias-managed = true<br/>Rollenzuordnungen, Mitglieder"]
end
C -- "schreibt die Kopie" --> K
K -- "Rollen der Gruppe" --> T["Token jedes Mitglieds"]
Lies es so: Eine Gruppe bündelt Rollen und hat Mitglieder. CIAS schreibt beides nach Keycloak. Keycloak legt die Rollen der Gruppe ins Token jedes Mitglieds, genau so, als hätte die Person sie einzeln bekommen.
Was zu einer Gruppe gehört
| Teil | Bedeutung |
|---|---|
key | der Schlüssel, zum Beispiel support. Er ändert sich nie. In Keycloak heißt die Gruppe genau so. Höchstens 128 Zeichen |
name | was Menschen lesen, zum Beispiel „Support 1st Level“. Fehlt er, nimmt CIAS den Schlüssel. Nur in CIAS, Keycloak zeigt den Schlüssel |
description | wofür die Gruppe da ist. In Keycloak steht sie im Attribut description |
roles | die Rollen, die die Gruppe vergibt: Realm-Rollen und Client-Rollen beliebig vieler Module, jede muss im Rollenkatalog stehen |
| Mitglieder | die Personen, über die ID ihres Benutzerdatensatzes in CIAS |
defaultGroup | ob jedes neue Konto automatisch Mitglied wird, siehe Die Standardgruppe |
syncState | ob die Kopie in Keycloak zum Stand in CIAS passt: SYNCHRONIZED oder PENDING, siehe Abgleich mit Keycloak |
Eine Rolle heißt in einer Gruppe immer Client plus Schlüssel, denn derselbe Schlüssel kann auf zwei Clients zwei verschiedene Rechte sein. Ein leerer Client bedeutet: Realm-Rolle. Mehr dazu unter Realm-Rolle, Client-Rolle, Organisationsrolle.
Die Ausprägungen
Wann: Die Gruppe trägt Rollen ohne Client, etwa user oder allowed-tenant-context-switch.
Realm-Rollen landen im Token unter realm_access.roles. Sie gelten in jedem Mandanten, egal welcher Art.
Ergebnis: wirkt überall
Wann: Die Gruppe trägt cdms-backend: customer-read und crms-backend: ticket-edit.
Genau dafür gibt es Gruppen: Eine Aufgabe im Unternehmen hält sich nicht an Modulgrenzen. Eine Kompositrolle könnte das nicht, sie lebt immer auf einem Client oder im Realm. Client-Rollen aus einer Gruppe landen unter resource_access.<client>.roles.
Ergebnis: wirkt, solange der Mandant der Anfrage keine eigenen Rollen trägt, siehe Gruppenrollen unter dynamischen Mandanten
Wann: Die Gruppe wird angelegt, die Rollen kommen später.
Das ist erlaubt. Eine Gruppe ohne Rollen gibt niemandem etwas, auch wenn sie schon Mitglieder hat.
Ergebnis: gültig, vergibt nichts
Wann: defaultGroup ist true.
Jedes Konto, das ab jetzt entsteht, wird Mitglied. Wer schon ein Konto hat, bleibt, wie er ist.
Ergebnis: siehe Die Standardgruppe
Plattformweit und flach
Eine Gruppe hat keinen Mandanten. Sie gilt auf der ganzen Plattform. Anna aus nordbau und Ben aus suedlogistik können in derselben Gruppe sein. Beide bekommen dieselben Rollen, üben sie aber nur auf den Daten ihres eigenen Mandanten aus. Die Gruppe verbindet die beiden nicht. Siehe Mandant, Organisation, Gruppe.
Eine Gruppe hat auch keine Untergruppen. Jede Gruppe steht für sich, und eine Person kann in mehreren Gruppen sein. Hat sie eine Rolle über zwei Wege, hat sie sie einfach, nicht doppelt.
Gruppe, Einzelvergabe, Vergabe im Mandanten
- viele Rollen auf einmal, über Module hinweg
- gilt global, ohne Mandant
- kein Enddatum, kein Grund je Person
- verwaltet nur der Plattform-Administrator
- Wer die Gruppe verlässt, verliert alle ihre Rollen
- eine Rolle mit Scope
PLATFORM - mit Enddatum und Grund
- als Vergabe in CIAS sichtbar
- verwaltet der Plattform-Administrator
- eine Rolle mit Scope
TENANT - gilt nur in diesem Mandanten
- mit Enddatum und Grund
- darf auch ein Mandanten-Administrator mit Delegation
Die Einzelvergaben stehen unter Eine Rolle vergeben.
| Mehrere Personen brauchen dasselbe Rollenbündel? | Soll es nur in einem Mandanten gelten? | Braucht es ein Enddatum je Person? | Nimm |
|---|---|---|---|
| – | ja | – | Vergabe im Mandanten, keine Gruppe |
| – | nein | ja | Einzelvergabe mit validUntil |
| ja | nein | nein | Gruppe |
| nein | nein | nein | Einzelvergabe, eine Gruppe lohnt sich nicht |
Zwei Systeme, eine feste Reihenfolge
Jede Änderung an einer Gruppe schreibt zweimal: in die CIAS-Datenbank und nach Keycloak. Eine gemeinsame Transaktion gibt es nicht. Deshalb gilt eine feste Regel:
| Was geschieht | Reihenfolge | Bricht es dazwischen ab … |
|---|---|---|
| etwas geben: Gruppe anlegen, Rolle dazu, Mitglied aufnehmen | erst CIAS, dann Keycloak | … steht es in CIAS, im Token noch nicht. Die Gruppe ist PENDING |
| etwas nehmen: Rolle weg, Mitglied entfernen, Gruppe löschen | erst Keycloak, dann CIAS | … ist das Recht schon weg, der Datensatz steht noch |
So bleibt nach einer Unterbrechung immer weniger Recht übrig, nie mehr. Wie ein liegengebliebenes PENDING wieder aufgeholt wird, steht unter Abgleich mit Keycloak.