CIAS als Brücke zum Identity Provider

Worum es geht

Zwischen einer CodamAI-Anwendung (zum Beispiel CDMS) und dem Identity Provider steht CIAS. Ein Identity Provider, kurz IdP, ist das System, bei dem sich Menschen anmelden. Bei CodamAI ist das heute Keycloak.

CIAS ist dabei eine Brücke. Auf der einen Seite stehen die Anwendungen mit ihren Rollen und Attributen, auf der anderen Seite steht der IdP mit Konten, Passwörtern und Tokens. CIAS verbindet beide Seiten und gibt der Anmeldung eine fachliche Bedeutung: wer die Person ist, zu welchem Mandanten sie gehört und welche Rechte sie trägt.

Warum eine Brücke und nicht einfach Keycloak direkt? Weil der IdP austauschbar bleiben soll. Heute steht dort Keycloak, morgen vielleicht ein anderes Produkt. Keine Anwendung und kein Fachmodul von CIAS kennt Keycloak. Nur ein einziger Baustein spricht mit Keycloak, der Adapter.

Wer macht was?

MFA heißt Multi-Faktor-Authentifizierung, also ein zweiter Nachweis neben dem Passwort, etwa ein Code aus einer App. Ein Token ist ein signierter Ausweis, den Keycloak nach der Anmeldung ausstellt. Die Anwendung schickt ihn bei jeder Anfrage mit.

CIAS tut, CIAS tut nicht

Die rechte Spalte ist keine Lücke, sondern Absicht. Die Frage, ob eine Funktion zu CIAS gehört, beantwortet eine einzige Linie: Fachliche Bedeutung liegt bei CIAS, technische Anmeldung beim IdP, die Durchsetzung auf den Daten bei der Anwendung.

Die Schreibrichtung

Rechte fließen immer in eine Richtung:

flowchart LR
    A["Anwendung<br/>(CDMS, CRMS, …)"] -- "meldet Rollen<br/>und Attribute an" --> C["CIAS<br/>Katalog, Vergaben,<br/>Gruppen, Werte"]
    C -- "schreibt über<br/>den Adapter" --> K["Keycloak<br/>Rollen, Gruppen,<br/>Profil, Mapper"]
    K -- "stellt Token aus" --> T(["Token"])
    T -- "bei jeder Anfrage" --> A

1. Die Anwendung meldet an, welche Rollen und Attribute sie kennt. Sie schreibt nichts selbst in Keycloak.
2. CIAS nimmt die Anmeldung in seinen Katalog auf, führt alle Vergaben und schreibt sie über den Adapter nach Keycloak.
3. Keycloak packt die Rollen und Attribute beim Anmelden ins Token.
4. Die Anwendung liest das Token und setzt die Rechte durch.

Die Leserichtung bei Konten

Bei den Konten selbst ist es umgekehrt. Ob ein Konto existiert und ob es aktiv ist, weiß Keycloak am besten. Dort melden sich die Menschen an, dort kann auch ein Betreiber ein Konto in der Konsole anlegen. CIAS gleicht sich daran an und kann bestehende Konten übernehmen, siehe Bestehende Konten übernehmen.

Den umgekehrten Weg gibt es genau einmal: Eine Registrierung erzeugt ein neues Konto. CIAS legt es dann selbst in Keycloak an.

Wie die Brücke gebaut ist

Innen besteht CIAS aus Fachmodulen (Registrierung, Benutzer, Rollen und Gruppen, Mandanten, Benachrichtigungen, Audit). Keines davon spricht direkt mit Keycloak. Jedes nutzt einen Port: eine Schnittstelle, die nur sagt, was gebraucht wird, etwa „lege ein Konto an“ oder „vergib diese Rolle“. Das Wie steckt im Adapter.

flowchart LR
    subgraph CIAS
      F["Fachmodule<br/>Registrierung, Benutzer,<br/>Rollen, Mandanten …"] --> P["Ports<br/>was gebraucht wird"]
    end
    P --> KA["Keycloak-Adapter"]
    P --> MA["Speicher-Adapter<br/>für Tests"]
    KA --> K["Keycloak"]

Wer den IdP wechselt, schreibt einen neuen Adapter. Die Fachmodule bleiben, wie sie sind. Details unter Ports und Adapter.

Eingebettet oder getrennt

CIAS läuft in zwei Betriebsarten. Fachlich verhält es sich in beiden gleich.

Mehr dazu unter Eingebettet und Getrennt.

Weiter

• Die Objekte und wem sie gehören: was CIAS speichert und was Keycloak davon als Kopie hält
• Die zwei Rechte-Matrizen: warum „was eine Rolle darf“ nicht in CIAS steht
• Was bei jeder Anfrage mit dem Token passiert