Worum es geht
Nur im getrennten Betrieb kann CIAS für sich allein ausfallen. Eingebettet steht und fällt CIAS mit der Anwendung: Ist CIAS weg, ist auch CDMS weg, und es gibt niemanden mehr, der fragen könnte.
Getrennt ist die Lage anders. Der CDMS-Dienst läuft weiter, kann CIAS aber nicht mehr erreichen – und muss trotzdem bei jeder Anfrage entscheiden.
Diese Seite beschreibt den Anfrageweg. Die Gesamtübersicht über Ausfälle, auch die von Keycloak und in der Verwaltung, steht unter Wenn CIAS oder Keycloak ausfällt.
Zwei Fragen, eine Regel
Auf dem Anfrageweg fragt der CDMS-Dienst CIAS zwei Dinge. Beide sind unabhängig voneinander gebaut und folgen derselben Regel:
| Frage | Wer fragt | Merkt sich | Wenn nichts gemerkt ist |
|---|---|---|---|
| Wird dieser Mandant bedient? | das Mandanten-Tor | jede Antwort, auch jedes Nein | die Anfrage wird abgelehnt |
| Was hält diese Person in diesem Mandanten? | der Attribut-Lookup | jede Antwort, auch eine leere | die Anfrage wird abgelehnt |
Die zweite Frage stellt sich nur, wenn ein Modul überhaupt ein Attribut pro Mandant angemeldet hat. Tut das keines, gibt es hier nichts, was ausfallen könnte: Die Werte im Token sind dann die ganze Wahrheit. Siehe Ein Wert pro Person oder pro Mandant.
Was als Ausfall zählt
Mehr, als man zuerst denkt. Jeder Fehlschlag beim Fragen ist ein Ausfall, denn keiner davon ist sicherer als der andere:
-
1CDMSkeine Verbindung nach 2 Sekunden, oder keine Antwort nach 2 SekundenDie Zeitlimits sind kurz und kein Stellknopf. Lieber scheitern als warten, denn für „gescheitert“ gibt es eine festgelegte Antwort.
-
2CDMSeine abgelehnte Verbindung, irgendein anderer Fehlercode von CIAS, eine Antwort, die sich nicht lesen lässt
-
3CDMSeine Antwort ohne das Feld
servedEin fehlendes Feld darf nie als „nicht bedient“ gelesen werden. Sonst würde eine Änderung am Antwortformat auf einen Schlag jeden Kunden ablehnen, und jedes Protokoll würde „gesperrt“ melden. -
4CDMSbeim Attribut-Lookup zusätzlich ein 404Ergebnis: Eine Person ohne Eintrag wird mit
200und leerer Liste beantwortet. Ein404heißt deshalb: diesen Endpunkt gibt es nicht.
Kein Ausfall ist dagegen ein 404 beim Mandanten-Lookup. Das ist eine richtige Antwort und heißt „diesen Schlüssel trägt kein Mandant“. Das Tor lehnt dann ab und merkt sich das.
Ein 401 oder 403 auf den Lookup ist ebenfalls kein Ausfall, sondern ein Urteil über die eigenen Zugangsdaten dieses Dienstes – und es führt sofort zur Ablehnung, ohne Umweg über das Gedächtnis. Der Grund liegt im Unterschied zu allen anderen Fehlern oben: Die gehen vorbei, sobald CIAS wieder antwortet. Ein abgewiesenes Dienst-Token tut das nicht, es wird erst durch ein neues gut.
Eingebettet gibt es dieselbe Regel, nur andere Ursachen: Der Methodenaufruf kann scheitern, etwa weil die System-Datenbank nicht erreichbar ist. Dann gilt derselbe Zweig.
Was das Tor dann antwortet
| Gemerkte Antwort für diesen Mandanten | Ergebnis für die Anfrage |
|---|---|
| vorhanden, höchstens 15 Minuten alt, und sie war „bedient“ | die Anfrage läuft normal weiter |
| vorhanden, höchstens 15 Minuten alt, und sie war „nicht bedient“ | 403 cias.authentication.tenant-not-served – eine gemerkte Ablehnung bleibt eine Ablehnung |
| vorhanden, aber älter als 15 Minuten | 403 cias.authentication.tenant-not-served |
| keine | 403 cias.authentication.tenant-not-served |
Solange CIAS nicht antwortet, bleibt es bei der gemerkten Antwort – aber höchstens 15 Minuten lang (codamai.cias.tenant-gate.stale-ceiling). Danach wird abgelehnt, als wäre nie etwas gemerkt worden. Die Merkzeit von 30 Sekunden entscheidet nur darüber, wann erneut gefragt wird – und gefragt werden kann erst wieder, wenn CIAS antwortet.
Die beiden Zeiten machen also Verschiedenes: Die Merkzeit gilt, solange CIAS antwortet, die Altersgrenze, während es nicht antwortet. Ohne die Grenze würde ein Dienst, der CIAS dauerhaft nicht erreicht, bis zu seinem Neustart aus dem Gedächtnis antworten – und nichts mehr davon mitbekommen, dass ein Mandant inzwischen gesperrt wurde.
Für die Attributwerte gilt Wort für Wort dasselbe: gemerkte Werte gelten weiter, ohne gemerkte Werte wird abgelehnt. Eine leere Antwort ist dabei eine vollwertige gemerkte Antwort, denn „diese Person hält hier nichts“ ist eine Aussage und keine fehlende.
Die Ausprägungen
Wann: In den letzten Sekunden vor dem Ausfall hat schon jemand aus diesem Mandanten gearbeitet.
Das Tor kennt die Antwort und gibt sie weiter. Für die Benutzer dieses Mandanten ändert sich nichts – vorausgesetzt, auch ihre Attributwerte sind gemerkt, falls es welche gibt. Alles, was CDMS ohne CIAS kann, geht weiter: lesen, schreiben, Dateien, Historie.
Ergebnis: Die Anfrage erreicht die Anwendung.
Wann: Für diesen Mandanten liegt nichts im Gedächtnis – niemand hat seit dem letzten Start des Knotens für ihn gearbeitet.
Das Tor hat keine Grundlage und lehnt ab. Das ist die Stelle, an der „im Zweifel zu“ wirkt: Eine Anfrage durchzulassen hieße, sich eine Antwort auf „darf dieser Kunde arbeiten?“ auszudenken.
Ergebnis: 403 cias.authentication.tenant-not-served – dieselbe Antwort wie für einen gesperrten oder unbekannten Kunden.
Wann: Der Mandant ist zugelassen, aber die Werte der Person in diesem Mandanten lassen sich nicht lesen und sind nicht gemerkt.
Die Filterkette lehnt ab, statt mit den Werten aus dem Token weiterzumachen oder mit gar keinen. Beides wäre gefährlich: Der Wert im Token gehört dem Mandanten, der ihn zuletzt geschrieben hat, und eine leere Liste ist nur ein * davon entfernt, einen Attributfilter ganz abzuschalten.
Ergebnis: 403 cias.authentication.tenant-not-served, mit demselben Schlüssel wie eine Mandantenablehnung.
Wann: Die Anwendung läuft in SINGLE, oder die Anfrage gehört zu keinem Mandanten.
Dann hat das Tor nichts zu fragen und der Attribut-Lookup nichts nachzuschlagen. Ein Ausfall von CIAS ist für solche Anfragen unsichtbar.
Ergebnis: Die Anfrage läuft normal.
Wann: Der CDMS-Knoten startet neu, während CIAS immer noch nicht antwortet.
Das Gedächtnis liegt nur im Speicher und ist nach dem Start leer. Der Knoten kennt dann keinen einzigen Mandanten.
Ergebnis: Jede Anfrage mit Mandant wird abgelehnt, bis CIAS wieder antwortet.
Was weiterläuft und was nicht
| Während CIAS nicht antwortet | |
|---|---|
| Anmelden und Token erneuern | geht, denn das macht Keycloak, nicht CIAS |
| Anfragen in einem gemerkten Mandanten | laufen weiter, solange die gemerkte Antwort keine 15 Minuten alt ist |
| Anfragen in einem Mandanten ohne gemerkte Antwort | werden abgelehnt |
| Anfragen, nachdem der Ausfall 15 Minuten gedauert hat | werden abgelehnt |
| Anfragen ohne Mandanten | laufen weiter |
| Ein neu angelegter Kunde | kann nicht arbeiten, bis CIAS antwortet |
| Die Verwaltungsoberfläche von CIAS | ist nicht erreichbar, denn sie liegt im CIAS-Dienst |
| Schreiben, Dateien, Historie in CDMS | laufen weiter, sie brauchen CIAS nicht |
Fallen
Weiter
- Die Mandantenprüfung in beiden Betriebsarten: wie die Frage gestellt wird
- Wenn CIAS oder Keycloak ausfällt: alle Ausfälle, auch außerhalb des Anfrageweges
- Im Zweifel ablehnen und Ablehnungen, die nichts verraten
- Den Mandanten zulassen (Mandanten-Tor)
- Der Weg des Tokens
- CIAS eingebettet und im Vergleich