Worum es geht
Dass ein Mandant im Token steht, heißt noch nicht, dass er arbeiten darf. Ein Kunde kann gesperrt sein, sein Vertrag kann abgelaufen sein, oder es gibt ihn gar nicht. Deshalb stellt die Filterkette bei jeder Anfrage eine zweite Frage: Wird dieser Mandant bedient?
Die Stelle, die diese Frage stellt, heißt Mandanten-Tor. Die Antwort gibt CIAS, denn dort wird geführt, welche Kunden es gibt und in welchem Zustand sie sind. CDMS führt dazu keine eigene Liste.
Das Tor im Weg der Anfrage
-
CIASToken prüfenIst das Token gültig?↳ nein 401
-
CIASMandant bestimmenNennt das Token eindeutig einen Mandanten?↳ nein 403
cias.authentication.tenant-unresolvedbzw.tenant-required -
CIASMandanten-TorWird dieser Mandant bedient?↳ nein 403
cias.authentication.tenant-not-served -
CIASMandantenwechselHeader
tenantgesetzt und erlaubt? Dann das Tor für das Ziel noch einmal fragen↳ nein 403cias.authentication.tenant-not-served, wenn das Ziel nicht bedient wird -
CDMSPersistenzzielMandant in der Liste der erlaubten Mandanten?↳ nein 403
CDMS_TENANT_SWITCH_NOT_AUTHORIZED - Zugriff auf die Datenbank des Mandanten
Das Tor steht vor CDMS. Es schützt also auch Anfragen, die gar keine Datenbank berühren, zum Beispiel eine Anfrage, die nur System-Modelle liest.
Wann ein Mandant bedient wird
CIAS antwortet mit ja, wenn beides stimmt:
- Der Mandant ist im Zustand aktiv.
- Das heutige Datum liegt in seinem Gültigkeitszeitraum (Beginn und Ende, beide optional, jeweils einschließlich).
| Mandant in CIAS | Zustand | heute im Gültigkeitszeitraum | CIAS erreichbar | Ergebnis |
|---|---|---|---|---|
| bekannt | aktiv | ja | ja | bedient, die Anfrage läuft weiter |
| bekannt | aktiv | nein | ja | 403 tenant-not-served |
| bekannt | in Bereitstellung, gesperrt oder geschlossen | – | ja | 403 tenant-not-served |
| unbekannt | – | – | ja | 403 tenant-not-served |
| – | – | – | nein, aber Antwort gemerkt | die gemerkte Antwort gilt, auch eine Ablehnung |
| – | – | – | nein, nichts gemerkt | 403 tenant-not-served |
Alle Ablehnungen sehen für den Client gleich aus. Das ist Absicht: Würde die Antwort verraten, ob es einen Mandanten gibt, könnte jeder mit einem gültigen Token die Kundenliste abfragen. Den genauen Grund findest du im Log von CDMS.
Die Zustände und wie ein Mandant sie wechselt, stehen unter Der Lebenslauf eines Mandanten und Mandanten sperren, schließen, Gültigkeit.
Das Tor merkt sich Antworten
Die Frage kommt bei jeder Anfrage, die Antwort ändert sich selten. Deshalb merkt sich das Tor jede Antwort für eine kurze Zeit, standardmäßig 30 Sekunden. Einstellbar ist das über codamai.cias.tenant-gate.ttl.
Wann: Die letzte Antwort für diesen Mandanten ist jünger als 30 Sekunden.
Das Tor nimmt die gemerkte Antwort und fragt CIAS nicht.
Ergebnis: Die meisten Anfragen kosten keine Rückfrage.
Wann: Keine Antwort gemerkt oder die gemerkte ist älter.
-
1CIASTor fragt CIAS: Wird
acmebedient? -
2CIASmerkt sich die Antwort für die nächsten 30 Sekunden
Ergebnis: Läuft CIAS in derselben Anwendung, ist das ein Methodenaufruf. Läuft CIAS als eigener Dienst, eine HTTP-Anfrage.
Wann: Die Rückfrage scheitert: Zeitüberschreitung, Verbindungsfehler, unlesbare Antwort.
-
1CIASTor hat eine gemerkte Antwort, egal wie alt → nimmt sie
-
2CIAS→Clientkeine gemerkte Antwort → 403
tenant-not-served
Ergebnis: Ein Ausfall von CIAS wirft niemanden hinaus, der schon gearbeitet hat, und lässt niemanden neu herein.
Die Einzelheiten zum Ausfall stehen unter Wenn CIAS nicht erreichbar ist.
Eine Sperre wirkt mit Verzögerung
sequenceDiagram
participant A as Admin
participant CIAS as CIAS
participant G as Mandanten-Tor
participant C as Client von acme
C->>G: Anfrage (0 s)
G->>CIAS: Wird acme bedient?
CIAS-->>G: ja, gemerkt für 30 s
A->>CIAS: acme sperren (10 s)
C->>G: Anfrage (20 s)
G-->>C: gemerkt: ja, läuft weiter
C->>G: Anfrage (35 s)
G->>CIAS: Wird acme bedient?
CIAS-->>G: nein
G-->>C: 403 tenant-not-served
Eine Sperre wirkt also spätestens nach der eingestellten Zeit. Wird sie länger gewählt, spart das Rückfragen, verlängert aber auch die Zeit, in der ein gesperrter Kunde weiterarbeitet.
Sonderfälle
Wann: Der Header tenant hat den Mandanten der Anfrage geändert.
Das Tor fragt ein zweites Mal, jetzt für das Ziel. Ein gesperrter Mandant bleibt für alle gesperrt, auch für Administratoren, die hineinwechseln.
Ergebnis: Siehe Mandantenwechsel per Header.
Wann: Das Token nennt keinen Mandanten.
Das Tor hat keine Frage zu stellen und lässt die Anfrage durch. In MULTI lehnt die Filterkette sie trotzdem ab, weil der Mandant fehlt, siehe Woher der Mandant einer Anfrage kommt.
Ergebnis: Anfragen ohne Anmeldung fragt das Tor ebenfalls nicht.
Wann: Der Mandant im Token ist kein gültiger Mandantenschlüssel, etwa mit Großbuchstaben.
Das Tor behandelt ihn wie einen unbekannten Mandanten, ohne CIAS zu fragen.
Ergebnis: 403 tenant-not-served
Wann: CODAMAI_PERSISTENCE_TENANT_MODE=SINGLE
CIAS bestimmt keinen Mandanten, also fragt das Tor auch nie. Ein Mandant im Token wird weder geprüft noch abgelehnt.
Ergebnis: Siehe In SINGLE zählt der Mandant im Token nicht.
Fallen
Wie es weitergeht
- Die Sicht von CIAS: Den Mandanten zulassen (Mandanten-Tor)
- Beide Betriebsarten nebeneinander: Die Mandantenprüfung in beiden Betriebsarten
- Was danach in CDMS passiert: Welche Datenbank? Das Persistenzziel