Der Support schaut in einen Mandanten

Worum es geht

Ben aus dem Mandanten nordbau meldet: „Ich sehe meine Aufträge nicht mehr.“ Lena arbeitet im Plattform-Support. Ihr eigener Mandant ist codamic, in nordbau ist sie kein Mitglied. Trotzdem soll sie nachsehen können, ohne sich ein Konto beim Kunden anlegen zu lassen.

Dafür gibt es zwei Header, die ein Client mitschicken kann:

• tenant: Die Anfrage läuft in einem anderen Mandanten.
• user: Die Anfrage läuft im Namen einer anderen Person. Mit dem Zusatz-Header user-roles: target auch mit deren Rollen.

Beide Header kann jeder setzen, also entscheidet nicht der Header, sondern das signierte Token. Jeder der beiden Wechsel hat seine eigene Realm-Rolle, also eine Rolle, die in Keycloak für die ganze Plattform gilt und die keine Organisation vergeben kann.

Was vorher eingerichtet sein muss

Die beiden Wechselrollen stehen in keinem Rollenkatalog und werden nicht über CIAS vergeben. Mehr dazu unter Die Realm-Rollen der Plattform.

Vorher: Ben gibt frei

Die Rolle allowed-user-context-switch erlaubt Lena, überhaupt die Person zu wechseln. Zu wem, entscheidet die Zielperson. Ben muss Lena den Wechsel freigeben, für nordbau, für den Modus und für eine begrenzte Zeit.

Ben kann die Freigabe jederzeit widerrufen. Die nächste Anfrage von Lena wird dann schon abgelehnt. Alle Regeln stehen unter Die Freigabe der Zielperson.

Eine Anfrage, Schritt für Schritt

Lenas Werkzeug schickt eine ganz normale Anfrage an CDMS, dazu die beiden Header:

POST /api/rest/order/query
Authorization: Bearer <Token von Lena, Mandant codamic>
tenant: nordbau
user: 3f2a…
{ "response": ["id", "orderNr", "price"] }

Die Suche läuft in der Datenbank von nordbau,
mit Lenas Rollen und Bens Benutzer-ID.
Mit zusätzlich "user-roles: target" liefe sie mit Bens Rollen.

sequenceDiagram
    participant C as Client
    participant F as Filterkette
    participant G as Mandanten-Tor
    participant D as CDMS
    participant DB as Datenbank nordbau
    C->>F: Token (codamic) + tenant nordbau + user 3f2a…
    F->>F: Header lesen, dann Token prüfen
    F->>F: auflösen: nordbau ist keine eigene Organisation → codamic
    F->>G: Wird codamic bedient?
    G-->>F: ja
    F->>F: Rollen und Attributwerte für codamic bestimmen
    F->>F: Rolle da, nordbau erlaubt → Mandant := nordbau
    F->>G: Wird nordbau bedient?
    G-->>F: ja
    F->>F: Lenas Werte pro Mandant für nordbau neu bestimmen
    F->>F: Rolle da, Ben bekannt, Mitglied von nordbau
    F->>F: Freigabe von Ben für Lena in nordbau? ja → Person := Ben
    F->>D: Anfrage weiterreichen
    D->>DB: suchen, mit Lenas Rollen und Bens ID
    DB-->>C: Zeilen

Zwei Dinge fallen an dieser Reihenfolge auf, und beide sind Absicht:

• Die Rollen werden vor dem Wechsel bestimmt, für Lenas Ausgangsmandanten, und gelten im Ziel unverändert weiter. Deshalb nimmt niemand durch einen Mandantenwechsel Rechte mit, die im Ziel vergeben sind. Lenas Werte pro Mandant dagegen werden für nordbau neu bestimmt, denn sie sagen, was sie dort sehen darf. Einzige Ausnahme ist der Benutzerwechsel mit user-roles: target: Dann gelten Bens Rollen und Werte, so wie sie in seinem eigenen Token für nordbau stünden.
• Der Benutzerwechsel kommt zuletzt, nach dem Mandantenwechsel und der zweiten Frage an das Tor. Deshalb muss Ben Mitglied von nordbau sein, nicht von codamic.
• Das Tor wird zweimal gefragt: einmal für den Mandanten aus dem Token, einmal für das Ziel. Ein gesperrter Mandant bleibt auch für den Support gesperrt.

Was Lena sieht und was nicht

Attributwerte sind Werte an einer Person, mit denen CDMS Zeilen aussiebt, etwa regionen. Anders als die Rollen werden Werte pro Mandant nach dem Wechsel für nordbau neu bestimmt; alle übrigen kommen aus Lenas Token. Ein Attributfilter siebt in nordbau also mit Lenas Werten für nordbau, nicht mit Bens, außer mit user-roles: target. Siehe Ein Wert pro Person oder pro Mandant und Attributfilter.

Die Ausprägungen

Was ein Wechsel hinterlässt

Mehr dazu unter Was eine Revision festhält und Welche Ereignisse protokolliert werden.

Fallen

Weiter

• Zwischen Mandanten wechseln und die Sicht von CDMS: Mandantenwechsel per Header
• Benutzerwechsel per Header
• Den Mandanten einer Anfrage bestimmen und Den Mandanten zulassen
• Effektive Rollen: global oder im Mandanten
• Der ganze Weg einer Anfrage: Vom Login bis zu den Daten