Woher der Mandant einer Anfrage kommt

Worum es geht

CDMS muss bei jeder Anfrage wissen, für welchen Mandanten sie läuft. Nur so findet es die richtige Datenbank. Der Mandant kommt aus dem Token, das Keycloak ausgestellt und signiert hat. Der Client schickt ihn nicht als eigenes Feld mit, und CDMS nimmt ihn auch aus keinem Feld der Daten.

Die Filterkette von CIAS liest das Token, bevor CDMS irgendetwas tut. Sie legt das Ergebnis im RequestContext ab. Das ist ein Speicher, der genau eine Anfrage lang lebt und am Ende gelöscht wird. Alles Spätere liest den Mandanten nur noch von dort.

Der Weg des Mandanten

flowchart LR
    T["Token<br/>organization: acme<br/>tenant: acme<br/>allowedTenants: …"] --> F["CIAS-Filterkette<br/>liest und prüft"]
    H["Header tenant<br/>(nur ein Wunsch)"] -.-> F
    F --> RC["RequestContext<br/>Mandant: acme<br/>erlaubte Mandanten: acme, …"]
    RC --> P["CDMS-Persistenz<br/>wählt die Datenbank"]
    P --> DB[("Datenbank acme")]

Wo der Mandant im Token steht

Keycloak kann den Mandanten auf zwei Arten ins Token schreiben:

• Organisation: Die Person ist Mitglied einer Organisation in Keycloak. Das Token trägt sie im Claim organization. Der Alias der Organisation, ihr Kurzname in Keycloak, ist der Mandantenschlüssel. So entstehen Mandanten, die CIAS zur Laufzeit anlegt.
• Attribut tenant: Die Person hat ein Benutzerattribut tenant mit dem Mandantenschlüssel. Das ist der fest zugeordnete Mandant.

Ein Mandantenschlüssel besteht nur aus Kleinbuchstaben, Ziffern und Bindestrichen, zum Beispiel acme oder stadtwerke-nord. Er ist zugleich der Name der Datenbank des Mandanten.

Wie Mandanten und Organisationen in CIAS entstehen, steht unter Statische und dynamische Mandanten.

Welcher Mandant gilt

Die Zeilen werden von oben nach unten gelesen. Einen Standard-Mandanten, auf den CIAS zurückfällt, gibt es nicht. Ein falscher Mandant wäre schlimmer als keine Antwort: Er würde einem Kunden die Daten eines anderen zeigen.

Was im RequestContext landet

Ist der Mandant bestimmt, prüft CIAS noch, ob er bedient wird. Danach schreibt es in den RequestContext:

Die Liste der erlaubten Mandanten begrenzt, wohin ein Mandantenwechsel überhaupt führen kann. Sie kommt aus dem signierten Token, nie aus einem Header. Das Attribut allowedTenants darf mehrere Werte haben oder eine durch Kommas getrennte Liste sein.

Varianten

Die Fehlerantworten der Filterkette

Lehnt die Filterkette ab, kommt die Antwort von CIAS und nicht von CDMS. Sie hat deshalb ein eigenes, kurzes Format:

POST /api/rest/crm/customer/query
Authorization: Bearer <Token mit zwei Organisationen, ohne Auswahl>

HTTP 403
{ "error": "cias.authentication.tenant-unresolved", "message": "request refused" }

Ein ungültiges oder abgelaufenes Token ist ein anderer Fall: Das ergibt 401, siehe Zugriff ohne Token.

Fallen

Wie es weitergeht

• Was mit dem Mandanten in der Persistenz passiert: Welche Datenbank? Das Persistenzziel
• Für einen anderen Mandanten arbeiten: Mandantenwechsel per Header
• Die Sicht von CIAS: Den Mandanten einer Anfrage bestimmen
• Wie ein Mandantenschlüssel aussieht: Der Mandantenschlüssel