Worum es geht
An jeder Anfrage sind mehrere Teile beteiligt, und jeder beantwortet andere Fragen. Wer weiß, welcher Teil wofür zuständig ist, sucht einen Fehler an der richtigen Stelle und baut eine Regel dort ein, wo sie hingehört.
Die Kette
flowchart LR
K["Keycloak<br/>meldet an,<br/>stellt Token aus"] --> T(["Token<br/>trägt Mandant,<br/>Rollen, Attribute"])
C["CIAS<br/>führt Mandanten, Rollen,<br/>Gruppen, Attribute"] -- "schreibt Rechte" --> K
T --> F["Filterkette von CIAS<br/>prüft Token und Mandant"]
F --> D["CDMS<br/>Rolle → Operation,<br/>Attribut → Zeilen"]
Lies es so: CIAS schreibt Rollen, Gruppen und Attribute nach Keycloak. Keycloak packt sie beim Anmelden ins Token. Bei jeder Anfrage prüft die Filterkette von CIAS das Token und den Mandanten. Danach entscheidet CDMS, was die Rollen auf den Daten erlauben.
Die Filterkette ist Code von CIAS, läuft aber vor CDMS im selben Programm, auch wenn CIAS selbst als eigener Dienst läuft. Siehe Eingebettet und getrennt im Vergleich.
Die vier Teile
- zeigt die Login-Seite
- prüft Passwort und MFA
- hält die Sitzung
- stellt Tokens aus und signiert sie
- führt Benutzer, Mandanten, Rollen, Gruppen, Attribute
- entscheidet, wer ein Recht vergeben darf
- schreibt Rechte als einziger in Keycloak
- prüft bei jeder Anfrage Token und Mandant
- trägt Person, Mandant, Rollen, Attribute
- gilt bis zu seinem Ablauf
- Rollen darin werden bei einer Anfrage nicht bei Keycloak nachgeprüft
- prüft, ob eine Rolle eine Operation auf einem Modell erlaubt
- filtert Zeilen nach Attributen und Besitzer
- wählt die Datenbank des Mandanten
- ruft die Hooks des Projekts auf
Was eine Rolle in CDMS erlaubt, steht im Modell. Du legst es im Hub fest, der Build erzeugt daraus den Code. CIAS kennt diese Tabelle absichtlich nicht. Siehe Die zwei Rechte-Matrizen.
Welche Frage welcher Teil beantwortet
Anmelden
| Frage | Zuständig | Mehr dazu |
|---|---|---|
| Stimmt das Passwort, ist die MFA erfüllt? | Keycloak | Anmelden im Browser |
| Wer stellt das Token aus und signiert es? | Keycloak | Anmelden im Browser |
| Ist das Token echt und nicht abgelaufen? | Filterkette von CIAS, ohne Keycloak zu fragen | Was bei jeder Anfrage mit dem Token passiert |
| Gibt es das Konto, ist es aktiviert? | Keycloak, CIAS gleicht sich daran an | CIAS als Brücke zum Identity Provider |
| Wer ist die Person fachlich, zu welchem Mandanten gehört sie? | CIAS | Der Benutzerdatensatz |
Mandant
| Frage | Zuständig | Mehr dazu |
|---|---|---|
| Welche Mandanten gibt es, und in welchem Zustand sind sie? | CIAS | Der Lebenslauf eines Mandanten |
| In welchem Mandanten läuft diese Anfrage? | Filterkette von CIAS, aus dem Token | Den Mandanten einer Anfrage bestimmen |
| Wird dieser Mandant gerade bedient? | Mandanten-Tor in der Filterkette, die Antwort gibt CIAS | Den Mandanten zulassen (Mandanten-Tor) |
| Darf die Person per Header in einen anderen Mandanten wechseln? | Filterkette von CIAS prüft die Realm-Rolle, CDMS prüft das Ziel gegen die erlaubten Mandanten | Mandantenwechsel per Header |
| In welche Datenbank geht der Zugriff? | CDMS, aus Modell-Ebene und Mandant | Welche Datenbank? Das Persistenzziel |
Rechte
| Frage | Zuständig | Mehr dazu |
|---|---|---|
| Welche Rollen und Attribute gibt es? | das Modul meldet sie an, CIAS führt den Katalog | Module melden ihre Rollen an |
| Wer darf eine Rolle vergeben? | CIAS: Delegation und Obergrenze | Eine Rolle vergeben |
| Wer schreibt Rollen, Gruppen und Attribute in Keycloak? | nur CIAS, über seinen Adapter | CIAS als Brücke zum Identity Provider |
| Welche Rollen gelten für genau diese Anfrage? | Filterkette von CIAS bildet die effektiven Rollen aus dem Token | Effektive Rollen: global oder im Mandanten |
| Welchen Wert hat ein Attribut in diesem Mandanten? | Token bei USER, CIAS bei USER_IN_TENANT | Ein Wert pro Person oder pro Mandant |
| Ab wann wirkt ein entzogenes Recht? | das Token: mit dem nächsten neuen Token | Warum ein Rechteentzug verzögert wirkt |
Daten
| Frage | Zuständig | Mehr dazu |
|---|---|---|
| Welche Rolle verlangt eine Operation auf einem Modell? | das Modell im Hub, daraus der generierte Code | Wie Rollennamen entstehen |
| Darf diese Rolle das Modell lesen, anlegen, ändern, löschen? | CDMS, Modellrolle | Modellrollen |
| Darf die Person über dieses Feld in ein anderes Modell? | CDMS, Rolle des Zielmodells oder Feldrolle | Rechte auf Beziehungen (Feldrollen) |
| Welche Zeilen sieht die Person? | CDMS: Owner-Filter, Attributfilter, eigene Filter | Die drei Ebenen im Überblick |
| Was soll beim Speichern fachlich zusätzlich passieren? | der Hook deines Projekts | Hooks: Arten und Zeitpunkte |
Nachvollziehen
| Frage | Zuständig | Mehr dazu |
|---|---|---|
| Wer hat wem wann welche Rolle gegeben, wer hat den Mandanten gesperrt? | CIAS, Audit | Eine Spur für alles |
| Wie sah ein Objekt früher aus, und wer hat es geändert? | CDMS, Historie | Historie lesen |
Eine Anfrage, Station für Station
Dieselbe Aufteilung zeigt sich im Weg einer Leseanfrage. An jeder Station steht, welcher Teil entscheidet:
-
FilterketteToken prüfenIst die Signatur von Keycloak echt, ist das Token nicht abgelaufen?↳ nein 401
-
FilterketteMandant auflösenWelcher Mandant steht im Token, ist er eindeutig?↳ nein 403
cias.authentication.tenant-unresolved -
CIASMandanten-TorWird dieser Mandant bedient?↳ nein 403
cias.authentication.tenant-not-served -
FilterketteEffektive Rollen und AttributeWelche Rollen und Attributwerte gelten in diesem Mandanten?
-
CDMSModellrolleErlaubt eine der Rollen das Lesen von
employee?↳ nein 403missing-permission|<rolle> -
CDMSZeilenfilterWelche Zeilen lassen Owner-Filter, Attributfilter und eigene Filter durch?↳ nein Zeile fehlt in der Liste
-
HookHookafter-Hook mit der Operation
READ, vor der Antwort - Die erlaubten Zeilen kommen zurück
Keycloak selbst kommt in diesem Weg nur einmal vor: Die Filterkette tauscht das Token bei Keycloak gegen eines für den Client von CIAS, oder sie nimmt es aus ihrem Cache. Ob Passwort und Rollen stimmen, fragt sie nicht noch einmal.