Worum es geht
CIAS verwaltet eine Handvoll Objekte: Benutzer, Mandanten, Rollen und so weiter. Für jedes Objekt gibt es zwei Fragen:
- Wem gehört es? Wer entscheidet, was es bedeutet, und wo liegt die maßgebliche Fassung?
- Was hält Keycloak davon? Viele Objekte gibt es auch in Keycloak, aber dort nur als Kopie, die CIAS geschrieben hat.
Die Ausnahme sind Anmeldedaten wie Passwort und MFA. Die gibt es nur in Keycloak.
Das Objektdiagramm
flowchart TB
MOD["Modul<br/>z. B. CDMS"] -- "meldet an" --> R["Rolle<br/>(client, key)"]
MOD -- "meldet an" --> AT["Attribut<br/>Katalogeintrag"]
U["Benutzer"] -- "gehört zu" --> M["Mandant"]
RV["Rollenvergabe<br/>von–bis, Zustand"] -- "wer" --> U
RV -- "was" --> R
RV -. "wo (optional)" .-> M
G["Gruppe"] -- "bündelt" --> R
U -- "Mitglied in" --> G
U -- "hat Werte für" --> AT
Lies es so: Ein Modul meldet Rollen und Attribute an. Eine Rollenvergabe verbindet einen Benutzer mit einer Rolle, optional in einem Mandanten. Eine Gruppe bündelt Rollen, und wer Mitglied ist, bekommt alle.
Die Tabelle
| Objekt | Was es ist | Gehört | Gegenstück in Keycloak |
|---|---|---|---|
| Benutzer | eine Person mit E-Mail, Anzeigename, Status und Heimatmandant | CIAS (fachlich), Keycloak (Anmeldung) | das Konto, mit Passwort, MFA und Sitzungen |
| Mandant | eine Kundeneinheit, deren Daten von anderen getrennt sind | CIAS | bei einem dynamischen Mandanten eine Organisation, bei einem statischen nichts |
| Rolle | ein benanntes Recht eines Moduls, etwa model-editor | das Modul bestimmt die Bedeutung, CIAS führt den Katalog | eine Realm-Rolle oder Client-Rolle |
| Rollenvergabe | „Person X hat Rolle Y, ab wann, bis wann, in welchem Mandanten“ | CIAS | eine Rollenzuordnung am Konto oder die Mitgliedschaft in einer Gruppe in der Organisation |
| Gruppe | ein Bündel von Rollen, auch über Module hinweg | CIAS | eine Gruppe im Realm, markiert als von CIAS verwaltet |
| Benutzerattribut | eine Notiz der Fachlichkeit zur Person | CIAS | keins |
| Profilattribut | ein Wert am Konto, der ins Token kommt, etwa projects | das Modul meldet es an, CIAS schreibt | Eintrag im User Profile des Realms, dazu ein Mapper ins Token |
| Modul | ein Baustein, der Rollen und Attribute braucht, etwa CDMS oder CRMS | die Installation vergibt den Namen | keins. Keycloak kennt nur den Client des Deployments |
Ein Realm ist in Keycloak ein abgeschlossener Bereich mit eigenen Konten und Rollen. Ein Client ist dort der Eintrag für ein Programm, das Tokens anfordert oder prüft.
Jedes Objekt im Einzelnen
Wann: Eine Person soll die Anwendung nutzen.
CIAS führt E-Mail, Anzeigename, Status (PENDING, ACTIVE, SUSPENDED, CLOSED) und den Heimatmandanten. Die E-Mail-Adresse ist das Konto: Es gibt eine Person pro Adresse. Verbunden sind CIAS-Datensatz und Keycloak-Konto über die ID des Kontos in Keycloak. Passwort, MFA und Sitzung gibt es nur in Keycloak. Weitere Mandanten außer dem Heimatmandanten führt CIAS nicht am Benutzer. Sie stehen in Keycloak, als Mitgliedschaft in einer Organisation oder im Attribut allowedTenants, und kommen über das Token. Mehr: Der Benutzerdatensatz.
Wann: Ein Kunde bekommt seinen eigenen, abgetrennten Datenbereich.
CIAS führt Schlüssel, Namen, Art (STATIC oder DYNAMIC), fachlichen Status, den Stand der Bereitstellung und eine Gültigkeit von–bis. Ein dynamischer Mandant hat in Keycloak eine Organisation; ihre ID merkt sich CIAS nur als Verweis. Ein statischer Mandant hat in Keycloak kein Gegenstück, die Zuordnung steht dann im Attribut tenant am Konto. Mehr: Statische und dynamische Mandanten.
Wann: Ein Modul braucht ein Recht, das es vergeben lassen will.
Eine Rolle heißt immer zweiteilig: Client und Schlüssel, also etwa cdms-backend und model-editor. Dazu führt CIAS den Scope (PLATFORM oder TENANT), das Modul, das sie angemeldet hat, und die Delegation: wer sie weitergeben darf. Ein Modul, das eine Rolle nicht mehr anmeldet, lässt sie stilllegen, nicht löschen. Mehr: Der Rollenkatalog.
Wann: Eine Person bekommt eine Rolle.
CIAS speichert jede Vergabe als eigenen Datensatz: wer, welche Rolle, in welchem Mandanten, von wann bis wann, von wem und warum. Der Zustand ist SCHEDULED (beginnt später), ACTIVE, EXPIRED oder REVOKED. In Keycloak wird eine globale Vergabe zur Rollenzuordnung am Konto. Eine Vergabe in einem Mandanten wird zur Mitgliedschaft in einer Gruppe innerhalb der Organisation, die genau diese Rolle trägt. Mehr: Eine Rolle vergeben und Befristete Rollen.
Wann: Viele Personen sollen dieselben Rollen bekommen.
CIAS führt Schlüssel, Namen, die Rollen und die Mitglieder. Eine Gruppe darf Rollen mehrerer Module zugleich tragen, aber nur Rollen, die im Katalog stehen. Eine Gruppe kann Standardgruppe sein: Jedes neue Konto tritt ihr bei. Keycloak bekommt eine Kopie jeder Gruppe, markiert mit cias-managed=true. Gruppen ohne diese Marke fasst CIAS nie an. Mehr: Was eine Gruppe ist.
Wann: Die Fachlichkeit will sich etwas über die Person merken.
Ein freies Schlüssel-Wert-Paar am CIAS-Datensatz der Person. Es bleibt in CIAS, geht nicht nach Keycloak und landet in keinem Token. Anmeldedaten gehören nie hierher. Mehr: Attribute einer Person pflegen.
Wann: Ein Modul muss etwas über die Person wissen, etwa für einen Attributfilter.
Das Modul meldet das Attribut an. CIAS nimmt es in seinen Attributkatalog auf, trägt es ins User Profile des Realms ein und legt den Mapper an, der es ins Token bringt. Der Wert selbst steht am Konto in Keycloak. Ist das Attribut pro Mandant angemeldet, liegt der Wert dagegen in CIAS, je Person und Mandant, und ersetzt bei jeder Anfrage den Wert aus dem Token. Mehr: Zwei Herkünfte von Attributen und Ein Wert pro Person oder pro Mandant.
Wann: Ein Baustein wie CDMS, CRMS oder CIAS selbst läuft in einem Deployment.
Ein Modul ist kein Datensatz, den man anlegt. Es meldet sich beim Start mit seinen Rollen und Attributen an. Seinen Namen vergibt die Installation, er muss eindeutig und stabil sein. Keycloak kennt das Modul nicht, sondern nur den Client des Deployments. Laufen CDMS, CIAS und CRMS in einem Programm, teilen sie sich einen Client. Mehr: Module melden ihre Rollen an.
Wem gehört was, auf einen Blick
- Passwort
- MFA
- Sitzung
- Verknüpfung mit externen Anmeldediensten
- Rollen
- Rollenvergaben
- Gruppen und Mitglieder
- Attribute im Profil
- Organisation eines dynamischen Mandanten
- Mandantenstatus und Gültigkeit
- Befristung und Grund einer Vergabe
- Delegation
- Benutzerattribute
- Attributwerte pro Mandant
- Registrierungen
Schreibreihenfolge: erst entziehen, zuletzt gewähren
Weil jedes Objekt an zwei Orten liegt, kann ein Schreibvorgang auf halbem Weg scheitern. CIAS schreibt deshalb in einer festen Reihenfolge:
| Vorgang | Reihenfolge | Bleibt bei einem Fehler dazwischen |
|---|---|---|
| etwas gewähren (Rolle, Gruppe, Mitglied hinzufügen) | erst CIAS, dann Keycloak | CIAS kennt es, im Token steht es noch nicht |
| etwas entziehen (Rolle, Mitglied entfernen, Gruppe löschen) | erst Keycloak, dann CIAS | Recht ist weg, der Datensatz steht noch |
In beiden Fällen hat die Person danach weniger Rechte, nie mehr. Der Abgleich beim Start oder auf Knopfdruck repariert den Rest. Mehr unter Die Schreibreihenfolge.