Zwischen Mandanten wechseln

Worum es geht

Eine Anfrage läuft normalerweise im Mandanten aus dem Token. Mit zwei Headern kann ein Client davon abweichen:

Header tenant: in einem anderen Mandanten arbeiten
Header user: im Namen einer anderen Person arbeiten

Beide Header kann jeder Client setzen, sie sind also nicht vertrauenswürdig. Ob sie wirken, entscheiden Angaben aus dem signierten Token.

Für den Header tenant unterscheidet CIAS zwei Fälle, die sehr verschieden behandelt werden:

Auswahl: Das Ziel ist eine Organisation, in der die Person selbst Mitglied ist. Keine besondere Rolle nötig.
Privilegierter Wechsel: Das Ziel ist ein Mandant, in dem die Person nicht Mitglied ist. Dafür braucht sie die Realm-Rolle allowed-tenant-context-switch, und das Ziel muss in ihrer Liste der erlaubten Mandanten stehen.

Eine Realm-Rolle ist eine Rolle, die in Keycloak für die ganze Plattform gilt, nicht nur in einem Mandanten. Keine Organisation kann sie vergeben.

Die Reihenfolge in der Filterkette

sequenceDiagram
    participant C as Client
    participant F as Filterkette
    participant G as Mandanten-Tor
    C->>F: Token (Mandant acme) + Header tenant: globex
    F->>F: Header lesen, dann Token
    F->>F: auflösen: globex eigene Organisation? nein → acme
    F->>G: Wird acme bedient?
    G-->>F: ja
    F->>F: Rollen und Attribute für acme bestimmen
    F->>F: Wechsel: Rolle allowed-tenant-context-switch? globex erlaubt? → Mandant := globex
    F->>G: Wird globex bedient?
    G-->>F: ja
    F-->>C: Anfrage läuft in globex, mit den Rollen aus acme

Die Auswahl passiert in der Auflösung, der privilegierte Wechsel danach. Deshalb bestimmt nur die Auswahl die Rollen: Die Rollen werden zwischen den beiden Schritten festgelegt.

Die Entscheidungstabelle

Was der Header tenant bewirkt (Betriebsart MULTI)

Ziel ist eigene Organisation	Realm-Rolle allowed-tenant-context-switch	Ziel in der Liste der erlaubten Mandanten	Ziel wird bedient	Ergebnis
ja	–	–	ja	Auswahl: läuft im Ziel, mit den Rollen der Mitgliedschaft dort
nein	ja	ja	ja	privilegierter Wechsel: läuft im Ziel, mit den eigenen Rollen
nein	nein	–	–	still ignoriert, läuft im eigenen Mandanten
nein	ja	nein	–	CIAS wechselt nicht; die Persistenz lehnt beim ersten Zugriff auf Mandanten-Daten ab
–	–	–	nein	403 `cias.authentication.tenant-not-served`

Die Liste der erlaubten Mandanten entsteht aus dem Token: der eigene Mandant, alle eigenen Organisationen und alle Einträge aus dem Benutzerattribut allowedTenants. Ein Header kann sie nicht erweitern.

Die Ausprägungen

Wechsel und Auswahl im Einzelnen

AuswahlPrivilegierter WechselOhne RolleZiel gesperrtBenutzerwechsel

Wann: Ben ist Mitglied in nordbau und suedlogistik und schickt tenant: suedlogistik.

1

Filterkette
Auflösung: suedlogistik ist eine eigene Organisation → gewählt
2

Filterkette
Tor für suedlogistik: ja
3

Filterkette
Rollen aus der Mitgliedschaft in suedlogistik

Ergebnis: Keine besondere Rolle nötig. Mitglied in zwei Firmen zu sein ist gewöhnlich.

Wann: Eine Support-Person mit Mandant acme, Rolle allowed-tenant-context-switch und globex in allowedTenants schickt tenant: globex.

1

Filterkette
Auflösung ergibt acme, Tor sagt ja, Rollen für acme
2

Filterkette
Rolle vorhanden, Ziel erlaubt → Mandant := globex
3

Filterkette
Tor für globex: ja

Ergebnis: Die Person arbeitet in globex mit ihren eigenen Rollen aus acme. Rollen, die jemand in globex hat, bekommt sie nicht.

Wann: Die Rolle fehlt, das Ziel ist keine eigene Organisation.

Der Wunsch wird nicht angewendet. Die Anfrage läuft im eigenen Mandanten, ohne Fehler und ohne Hinweis in der Antwort.

Ergebnis: Siehe Falle „Der stille Fall“ unten.

Wann: Der Wechsel wäre erlaubt, aber globex ist gesperrt, geschlossen oder unbekannt.

Das zweite Tor lehnt ab. Auch Administratoren sind nicht ausgenommen: Ein gesperrter Mandant ist für alle gesperrt.

Ergebnis: 403 cias.authentication.tenant-not-served. Einen gesperrten Mandanten verwaltest du über die Verwaltungs-API, nicht über den Wechsel.

Wann: Die Anfrage trägt den Header user: 3f2a….

Mit der Realm-Rolle allowed-user-context-switch werden ID und Name der Person im RequestContext die der Zielperson. Der Mandant bleibt. Rollen und Attribute bleiben die der angemeldeten Person, mit dem Header user-roles: target werden es die der Zielperson. Ohne die Rolle, bei einer unbekannten Person oder einer Person, die nicht zum Mandanten der Anfrage gehört, antwortet CIAS mit 403 cias.authentication.user-switch-denied. Hat die Zielperson den Wechsel nicht freigegeben, mit 403 cias.authentication.user-switch-not-consented.

Ergebnis: Jeder Wechsel braucht seine eigene Realm-Rolle. Kommen beide Header zusammen, wird zuerst der Mandant gewechselt, und die Zielperson muss zum Ziel-Mandanten gehören. Mehr unter Benutzerwechsel per Header.

Was nach einem privilegierten Wechsel über den Mandanten bekannt ist

Code in einem Modul kann bei CIAS nicht nur den Schlüssel des aktuellen Mandanten abfragen, sondern auch seine Beschreibung: Art und Organisation. Nach einem privilegierten Wechsel gibt es diese Beschreibung nicht. Die Auflösung hat ja den Ausgangsmandanten beschrieben, nicht das Ziel. CIAS liefert dann nur den Schlüssel und eine leere Beschreibung, statt dem Code Angaben über den falschen Kunden zu geben.

Fallen

Weiter

Die Sicht von CDMS: Mandantenwechsel per Header
Ein Beispiel von Anfang bis Ende: Der Support schaut in einen Mandanten
Den Mandanten einer Anfrage bestimmen