Den Mandanten einer Anfrage bestimmen

Worum es geht

Jede angemeldete Anfrage läuft unter höchstens einem Mandanten. Welcher das ist, bestimmt die Filterkette von CIAS, bevor irgendein Modul die Anfrage sieht. Diesen Schritt nennt CIAS Auflösen. Er beantwortet nur die Frage „welcher Mandant?“. Ob dieser Mandant arbeiten darf, prüft danach das Mandanten-Tor.

Die Auflösung liest drei Angaben:

• die Organisationen im Token (Claim organization), also die dynamischen Mandanten, in denen die Person Mitglied ist
• das Attribut tenant im Token, den fest zugeordneten Mandanten
• den Header tenant der Anfrage, einen Wunsch des Clients

Die Regeln

Die Regeln werden von oben nach unten geprüft. Die erste, die passt, entscheidet.

flowchart TB
    S([Token gelesen]) --> O{"Organisationen<br/>im Token?"}
    O -- "keine" --> A{"Attribut tenant?"}
    A -- "fehlt" --> NONE["NONE<br/>ohne Mandant"]
    A -- "gesetzt" --> RS["RESOLVED<br/>statischer Mandant"]
    O -- "eine oder mehrere" --> C{"Attribut tenant nennt<br/>keine davon?"}
    C -- "ja" --> CON["CONFLICT<br/>403"]
    C -- "nein oder fehlt" --> H{"Header tenant nennt<br/>eine davon?"}
    H -- "ja" --> R1["RESOLVED<br/>die gewählte"]
    H -- "nein" --> T{"Attribut tenant<br/>nennt eine davon?"}
    T -- "ja" --> R2["RESOLVED<br/>die aus dem Attribut"]
    T -- "nein" --> E{"genau eine?"}
    E -- "ja" --> R3["RESOLVED<br/>diese eine"]
    E -- "nein" --> AMB["AMBIGUOUS<br/>403"]

Der Widerspruch (CONFLICT) wird vor der Auswahl per Header geprüft. Sonst könnte eine falsch eingerichtete Person, die ein Attribut tenant hat und zugleich Mitglied in Organisationen ist, per Header in jede ihrer Organisationen gesteuert werden.

Die vier Ergebnisse

In SINGLE findet die Auflösung gar nicht statt: Jedes Token gilt dort als Token ohne Mandanten, auch eines mit Organisationen. Siehe In SINGLE zählt der Mandant im Token nicht.

NONE ist für sich keine Ablehnung. Ein Token ohne Mandanten hieß schon immer „ohne Mandant“, und eine Anfrage ohne Mandanten darf nichts, was einen Mandanten braucht. Abgelehnt wird sie erst, wenn die Installation Mandanten trennt (MULTI). Die Pfade unter /cias/** bleiben dann erreichbar, damit die Person ihr Profil sehen und ein Administrator den fehlenden Mandanten nachtragen kann.

Die beiden Schlüssel tenant-unresolved und tenant-required trennen zwei Fehler, die an verschiedenen Stellen behoben werden: „du hast nicht eindeutig gewählt“ behebt der Client, „dir wurde nie ein Mandant zugeordnet“ behebt ein Administrator in CIAS.

Auswahl ist kein Wechsel

Der Header tenant dient zwei Zwecken, und die Auflösung kümmert sich nur um den ersten:

• Auswahl: Der Header nennt eine Organisation, in der die Person selbst Mitglied ist. Das ist gewöhnlich und braucht keine besondere Rolle. Die Auflösung wählt diese Organisation, und die Rollen der Person in dieser Organisation gelten.
• Wechsel: Der Header nennt einen Mandanten, in dem die Person nicht Mitglied ist. Das ist privilegiert und passiert erst nach Auflösung und Tor. Siehe Zwischen Mandanten wechseln.

Damit die Auswahl rechtzeitig wirkt, liest die Filterkette die Header vor dem Token. Die gewählte Organisation entscheidet ja, welche Rollen die Person hat.

Was nach der Auflösung im RequestContext steht

Der RequestContext ist der Speicher, der genau eine Anfrage lang lebt. Die Auflösung füllt ihn, nachdem das Tor zugestimmt hat:

Die eigenen Organisationen stehen mit in der Liste der erlaubten Mandanten. Sonst würde die Persistenz eine Person ablehnen, die ihre zweite Organisation auswählt.

Fallen

Weiter

• Den Mandanten zulassen (Mandanten-Tor)
• Zwischen Mandanten wechseln
• Die Sicht von CDMS: Woher der Mandant einer Anfrage kommt