Vom Login bis zu den Daten

Worum es geht

Das hier ist der Weg, den jede Anfrage in einer CodamAI-Anwendung geht. Eine Person meldet sich an, klickt auf „Kunden“ und sieht eine Liste. Dazwischen liegen sechs Programme, und jedes tut genau eine Sache.

Wenn du diese Seite verstanden hast, kannst du jede andere Seite lesen: Alle anderen Abläufe sind Abzweigungen von diesem einen.

Wer welche Farbe hat und wer überhaupt beteiligt ist, steht unter Die Beteiligten einer Anfrage. Diese Seite spielt den Weg einmal von vorn bis hinten durch.

Die zwei Hälften

Der Ablauf zerfällt in zwei Teile, die nichts miteinander zu tun haben – außer dass der zweite den ersten voraussetzt:

Teil 1: Anmelden

sequenceDiagram
    autonumber
    participant B as Browser
    participant F as BFF
    participant K as Keycloak
    B->>F: öffnet /kunden
    F-->>B: keine Sitzung, Weiterleitung auf /login
    B->>K: Login-Seite von Keycloak
    K-->>B: Passwort, ggf. Einmalcode
    B->>K: Eingaben
    K-->>B: Weiterleitung zurück mit einem einmaligen Code
    B->>F: /api/auth/callback/keycloak?code=…
    F->>K: tauscht den Code gegen Tokens
    K-->>F: Access-, Refresh- und ID-Token
    F-->>B: verschlüsseltes Sitzungs-Cookie, zurück auf /kunden

Drei Dinge daraus, die den Rest der Seite tragen:

• Das Passwort sieht nur Keycloak. Die Anwendung bekommt es nie. Details unter Anmelden im Browser.
• Die Tokens liegen im BFF, im Browser liegt nur ein verschlüsseltes Cookie. Details unter Sitzung im BFF und Cookies.
• Das Access-Token ist der Ausweis für alles Weitere. Es gilt kurz (voreingestellt 5 Minuten) und wird vor Ablauf erneuert, siehe Token erneuern.

Teil 2: Der Klick auf „Kunden“

Jetzt kommt der Weg, um den es hier geht. Die Person ist angemeldet und klickt in der Oberfläche auf „Kunden“.

sequenceDiagram
    autonumber
    participant U as Benutzer
    participant B as Browser
    participant F as BFF
    participant K as Keycloak
    participant FK as Filterkette (CIAS)
    participant T as Mandanten-Tor (CIAS)
    participant C as CDMS
    participant DB as Mandanten-DB
    U->>B: klickt auf „Kunden“
    B->>F: GET /api/kunden, Sitzungs-Cookie geht mit
    F->>F: Cookie entschlüsseln, Access-Token herausnehmen
    opt Token läuft bald ab
        F->>K: POST /token, grant_type=refresh_token
        K-->>F: neues Access-Token
    end
    F->>FK: POST /api/rest/crm/customer/query<br/>Authorization: Bearer …
    FK->>FK: Signatur und Ablauf prüfen
    FK->>K: Token tauschen (oder aus dem Cache)
    K-->>FK: Token für den CIAS-Client
    FK->>FK: Identität lesen, Mandant auflösen
    FK->>T: wird nordbau bedient?
    T-->>FK: ja (30 s gemerkt)
    FK->>FK: effektive Rollen und Attribute bilden
    FK->>C: RequestContext gefüllt, weiterreichen
    C->>C: response auflösen (welche Felder?)
    C->>C: Leserolle für customer prüfen
    C->>C: Sicherheitsfilter anhängen (Besitzer, Attribute, eigene)
    C->>DB: SELECT der erlaubten Spalten und Zeilen
    DB-->>C: Zeilen
    C->>C: READ-Hook je Zeile, dann in DTOs umwandeln
    C-->>F: 200 mit data und meta
    F-->>B: die Liste als JSON der eigenen Route
    B-->>U: die Tabelle erscheint

Das ist der ganze Weg. Die folgenden Abschnitte gehen ihn in vier Etappen noch einmal langsam durch.

Etappe 1: Browser und BFF

Der Browser ruft nie CDMS oder CIAS direkt auf. Er ruft eine Route des eigenen Frontends auf, und die liegt auf dem BFF, dem Server-Teil der Oberfläche.

Warum dieser Umweg? Weil das Token im Browser von jedem Skript der Seite lesbar wäre. Im BFF ist es das nicht. Die ganze Begründung steht unter Sitzung im BFF und Cookies.

Der BFF ist außerdem die Stelle, an der aus einer fachlichen Route („gib mir die Kunden“) eine CDMS-Anfrage wird: Er setzt die Feldauswahl (response) und die Suchparameter zusammen. Siehe Aufbau einer Suche.

Etappe 2: Die Filterkette von CIAS

Die Anfrage kommt beim Backend an – und läuft dort zuerst durch die Filterkette von CIAS, noch bevor eine einzige Zeile CDMS-Code läuft.

Das Ergebnis heißt RequestContext: ein Merkzettel, der genau für diese eine Anfrage gilt. Darin stehen Benutzer-ID, Name, Mandant, erlaubte Mandanten, Rollen, Gruppen, Attribute – dazu IP-Adresse und Browser-Kennung, die die Filterkette aus der Anfrage gelesen hat. Alles danach liest nur noch dort nach, nie wieder im Token.

Zwei Punkte, die man leicht übersieht:

• Die Filterkette ist immer Teil des CDMS-Prozesses, auch wenn CIAS als eigener Dienst läuft. Sie ist ein Jar, kein Server.
• Sie räumt den Merkzettel nach der Antwort wieder ab. Der nächste Aufruf auf demselben Thread fängt leer an.

Jede Station im Einzelnen steht unter Was bei jeder Anfrage mit dem Token passiert, die Mandantenfrage unter Die Mandantenprüfung in beiden Betriebsarten.

Etappe 3: CDMS

Jetzt erst ist CDMS dran. Es sieht kein Token, nur den RequestContext.

Die Stationen innerhalb von CDMS haben eine eigene Seite: Der Weg einer Anfrage durch die Schichten. Welche Zeilen eine Person sieht, steht unter Die drei Ebenen im Überblick.

Etappe 4: Zurück zum Bildschirm

Der Rückweg ist kurz, hat aber zwei Besonderheiten:

• Vor dem Schreiben der Antwort schreibt CDMS seine Transaktion fest. Beim Lesen fällt das nicht auf, beim Schreiben ist es der entscheidende Punkt – siehe Ein Schreibvorgang über alle Schichten.
• Der BFF gibt die Daten nicht roh weiter. Er formt sie in das um, was die Oberfläche braucht, und übersetzt Fehler: Ein missing-permission|projekt wird zu „dir fehlt eine Rolle für dieses Modell“, ein tenant-required zu „dein Konto gehört zu keinem Mandanten“. Die Oberfläche schickt jemanden damit an die richtige Stelle statt auf die Login-Seite.

Derselbe Weg in beiden Betriebsarten

CDMS und CIAS können in einem Prozess laufen oder als zwei Dienste. Der Weg der Anfrage ist derselbe – nur die Frage „wird der Mandant bedient?“ nimmt einen anderen Weg.

sequenceDiagram
    autonumber
    participant F as BFF
    participant FK as Filterkette (CIAS)
    participant T as Mandanten-Tor (CIAS)
    participant U as cias-user
    participant C as CDMS
    participant DB as Mandanten-DB
    F->>FK: POST /api/rest/crm/customer/query + Token
    FK->>FK: Token prüfen, tauschen, Mandant auflösen
    FK->>T: darf nordbau bedient werden?
    Note over FK,T: Methodenaufruf, kein Netz
    T-->>FK: ja (30 s gemerkt)
    FK->>U: welche Attributwerte gelten hier?
    U-->>FK: regionen = [nord]
    FK->>C: RequestContext gefüllt
    C->>DB: SELECT der erlaubten Zeilen
    DB-->>C: Zeilen
    C-->>F: data + meta

sequenceDiagram
    autonumber
    participant F as BFF
    participant FK as Filterkette (im CDMS-Dienst)
    participant TC as cias-tenancy-client
    participant S as CIAS-Dienst
    participant C as CDMS
    participant DB as Mandanten-DB
    F->>FK: POST /api/rest/crm/customer/query + Token
    FK->>FK: Token prüfen, tauschen, Mandant auflösen
    FK->>TC: darf nordbau bedient werden?
    TC->>S: GET /cias/lookup/tenants/nordbau<br/>mit dem Dienst-Token von CDMS
    S-->>TC: 200 served: true
    TC-->>FK: ja (30 s gemerkt)
    FK->>TC: welche Attributwerte gelten hier?
    TC->>S: GET /cias/lookup/users/{id}/attributes?tenantKey=nordbau
    S-->>TC: regionen = [nord]
    TC-->>FK: Werte
    FK->>C: RequestContext gefüllt
    C->>DB: SELECT der erlaubten Zeilen
    DB-->>C: Zeilen
    C-->>F: data + meta

Die Unterschiede in voller Breite stehen unter Eingebettet und getrennt im Vergleich. Für den Anfrageweg zählt vor allem: Die Filterkette läuft in beiden Fällen im CDMS-Prozess, und die Antwort der beiden Lookups wird 30 Sekunden gemerkt. Was passiert, wenn der CIAS-Dienst schweigt, steht unter Wenn CIAS nicht erreichbar ist.

Was in welcher Anfrage steckt

Drei Anfragen hintereinander, und jede sieht anders aus:

Wo der Weg endet, wenn etwas fehlt

Zwei Arten von 403 also, und sie sehen verschieden aus: Die Filterkette schreibt { "error": …, "message": … }, CDMS schreibt { "messageKey": …, "code": …, "layer": … }. Am Feldnamen erkennst du sofort, wer abgelehnt hat. Siehe 401, 403 oder 404?.

Eine leere Liste ist übrigens kein Fehler und sieht genauso aus wie „es gibt nichts“. Das ist gewollt: Wer eine Zeile nicht sehen darf, soll nicht daraus schließen können, dass es sie gibt. Siehe Warum Unsichtbares 404 liefert.

Fallen

Wie es weitergeht

• Der Weg des Tokens: wie Mandant, Rollen und Attribute ins Token kommen
• Die Mandantenprüfung in beiden Betriebsarten
• Ein Schreibvorgang über alle Schichten: derselbe Weg, aber mit Speichern
• Wenn CIAS nicht erreichbar ist
• Der Weg einer Anfrage durch die Schichten: die CDMS-Hälfte im Detail
• Was bei jeder Anfrage mit dem Token passiert: die CIAS-Hälfte im Detail