Worum es geht
CIAS und Keycloak sind zwei verschiedene Dienste, und beide können einmal ausfallen. Was dann passiert, hängt davon ab, wer gerade wen fragt:
- CIAS beantwortet bei jeder Anfrage an CDMS die Frage „wird dieser Mandant bedient?“ und, wenn eingerichtet, „welche Attributwerte hat die Person in diesem Mandanten?“.
- Keycloak stellt Tokens aus, tauscht sie und nimmt jede Änderung an Konten, Rollen und Organisationen entgegen.
Beide Fragen bei jeder Anfrage live zu stellen, wäre langsam und zerbrechlich. Deshalb merkt sich die Filterkette die Antworten eine kurze Zeit. Bei einem Ausfall entscheidet genau dieses Gedächtnis, wer weiterarbeiten kann.
Wer wen wann fragt
flowchart LR
C["Client"] --> F["Filterkette"]
F -- "Schlüssel zur Signaturprüfung<br/>(eine Zeit lang gemerkt)" --> K["Keycloak"]
F -- "Token tauschen<br/>(je Token bis 5 min gemerkt)" --> K
F -- "Mandant bedient?<br/>(30 s gemerkt)" --> CI["CIAS"]
F -- "Attributwerte im Mandanten<br/>(30 s gemerkt)" --> CI
R["Registrierung,<br/>Verwaltung"] -- "live, nichts gemerkt" --> K
Lies es so: Die Filterkette braucht Keycloak und CIAS bei jeder Anfrage, merkt sich aber die Antworten. Registrierung und Verwaltung sprechen dagegen live mit Keycloak, denn sie ändern etwas.
| Schritt | fragt | merkt sich | bei Ausfall |
|---|---|---|---|
| Token-Signatur prüfen | Keycloak, nach den öffentlichen Schlüsseln des Realms | die Schlüssel, eine Zeit lang | Solange die Schlüssel da sind, braucht die Prüfung Keycloak nicht. Braucht sie neue und bekommt keine, scheitert die Anfrage. |
| Token tauschen | Keycloak | das getauschte Token, je Token bis zu 5 Minuten (codamai.cias.token-exchange.ttl), nie länger als es gilt | Ein schon getauschtes Token wirkt weiter. Für ein neues Token siehe unten. |
| Mandant zulassen | CIAS | jede Antwort 30 Sekunden (codamai.cias.tenant-gate.ttl) | die letzte Antwort, solange sie höchstens 15 Minuten alt ist (codamai.cias.tenant-gate.stale-ceiling), sonst 403 |
| Attributwerte pro Mandant | CIAS | jede Antwort 30 Sekunden (codamai.cias.attribute-lookup.ttl) | die letzten Werte, solange sie höchstens 15 Minuten alt sind (codamai.cias.attribute-lookup.stale-ceiling), sonst 403 |
| Anmelden, Token erneuern | Keycloak | nichts | geht nicht |
CIAS weg
Fällt CIAS aus, arbeitet die Filterkette mit dem, was sie sich gemerkt hat. Die Regel ist für das Mandanten-Tor und die Attributwerte dieselbe:
| Gemerkte Antwort | Ergebnis |
|---|---|
| vorhanden, höchstens 15 Minuten alt | die gemerkte Antwort gilt weiter, auch wenn sie Nein war |
| vorhanden, aber älter | 403 cias.authentication.tenant-not-served |
| keine | 403 cias.authentication.tenant-not-served |
In einem Satz: Ein Ausfall von CIAS wirft niemanden hinaus, der schon gearbeitet hat, und lässt niemanden neu herein. Ein Mandant, der zuletzt gesperrt war, bleibt gesperrt. Eine Person behält die Werte, mit denen sie zuletzt gearbeitet hat, und bekommt keine neuen.
Das gilt aber nicht unbegrenzt. Die 15 Minuten sind die Altersgrenze: Sie überbrücken einen Neustart oder eine Auslieferung, ohne dass jemand abgelehnt wird. Dauert der Ausfall länger, hört die Filterkette auf, aus dem Gedächtnis zu antworten, und lehnt ab. Der Grund ist einfach: Solange sie aus dem Gedächtnis antwortet, erfährt sie nichts Neues – eine Sperre, die in dieser Zeit ausgesprochen wird, käme sonst nie an.
Was „nicht antwortet“ heißt, hängt von der Betriebsart ab:
| eingebettet | getrennt | |
|---|---|---|
| Wie gefragt wird | Methodenaufruf im selben Prozess | HTTP-Anfrage mit einem Dienst-Token |
| Was als Ausfall zählt | die Abfrage wirft einen Fehler, etwa weil die System-Datenbank nicht erreichbar ist | keine Verbindung nach 2 Sekunden, keine Antwort nach 2 Sekunden, ein Fehlercode, eine unlesbare Antwort |
| Was nicht als Ausfall zählt | – | 404: CIAS kennt den Mandanten nicht, das Tor lehnt ab und merkt sich das |
| Was sofort ablehnt | – | ein abgelehntes Dienst-Token (401 oder 403): die Anfrage wird abgelehnt, auch wenn etwas Passendes gemerkt ist |
Das Dienst-Token ist ein Sonderfall, weil es nicht von selbst wieder gut wird. Getrennt betrieben meldet sich CDMS bei CIAS mit einem festen Token an. Lehnt CIAS es ab, ist es abgelaufen oder falsch gesetzt, und jede weitere Frage scheitert genauso – bis jemand es austauscht. Deshalb wird hier abgelehnt statt überbrückt: Ein Ausfall, der nicht vorbeigeht, würde sonst dauerhaft aus dem Gedächtnis beantwortet.
Die Einzelheiten zum Tor stehen unter Den Mandanten zulassen (Mandanten-Tor). Das gilt genauso für Arbeit ohne Anfrage, etwa einen Zeitgeber, der für einen Mandanten läuft, siehe Arbeiten für einen Mandanten ohne Anfrage.
Keycloak weg bei einer Anfrage
Wann: Die Person arbeitet gerade, ihr Token wurde in den letzten Minuten schon einmal getauscht.
Die Filterkette nimmt das getauschte Token aus ihrem Gedächtnis und fragt Keycloak nicht. Die Anfrage läuft ganz normal, solange Token und gemerkter Tausch gelten.
Ergebnis: Die Anfrage erreicht die Anwendung.
Wann: Ein neues Token soll getauscht werden, Keycloak antwortet, aber mit einem Fehlercode.
CIAS schreibt einen Fehler ins Log und lässt die Anfrage ohne Identität weiter. Die Anwendung sieht keine Person und keine Rollen.
Ergebnis: Jede Rollenprüfung lehnt ab, meist mit 403. Siehe Token-Tausch.
Wann: Ein neues Token soll getauscht werden, aber Keycloak ist gar nicht erreichbar.
Der Tausch scheitert, bevor es eine Antwort gibt.
Ergebnis: Die Anfrage scheitert.
Wann: Die Person meldet sich neu an, oder ihr Token läuft ab und soll erneuert werden.
Tokens stellt nur Keycloak aus. Ohne Keycloak gibt es kein neues Token.
Ergebnis: Die Person kann erst weiterarbeiten, wenn Keycloak wieder da ist. Siehe Token erneuern.
Das Mandanten-Tor ist von Keycloak unabhängig. Es fragt CIAS, nicht Keycloak.
Keycloak weg bei der Registrierung
Die Registrierung spricht an mehreren Stellen live mit Keycloak. Ist Keycloak nicht erreichbar, antwortet CIAS mit 503 cias.iam.unavailable. Was danach übrig ist, hängt vom Schritt ab:
Wann: POST /cias/registration/self, oder ein Administrator legt eine Person an oder lädt sie ein.
CIAS fragt Keycloak als Erstes, ob es die Adresse schon gibt. Scheitert das, ist noch nichts gespeichert und keine Mail verschickt.
Ergebnis: 503. Die Person schickt das Formular später noch einmal ab.
Wann: Die Person klickt den Bestätigungslink, und die Bereitstellung beginnt sofort.
Die Bereitstellung scheitert an Keycloak. CIAS setzt den Vorgang auf FAILED und speichert das. Ein zweiter Klick auf denselben Link antwortet mit 202, setzt die Bereitstellung aber nicht fort: Der Link ist schon eingelöst.
Ergebnis: 503 beim ersten Klick. Weiter geht es nur mit retry durch einen Plattform-Administrator.
Wann: Ein Administrator genehmigt einen Vorgang, schaltet ihn ohne Link frei oder ruft retry auf.
Auch hier beginnt die Bereitstellung und scheitert an Keycloak. Der Vorgang steht danach auf FAILED.
Ergebnis: 503. Später retry aufrufen.
Jede Speicherung der Registrierung ist ein eigener kleiner Schritt. Deshalb bleibt der Zustand FAILED auch dann gespeichert, wenn die Anfrage mit einem Fehler endet. Ein Plattform-Administrator findet den Vorgang in der Liste mit state=FAILED. Siehe Was beim Abschluss passiert.
Keycloak weg bei der Verwaltung
Wer Rechte ändert, schreibt in CIAS und in Keycloak. Fällt Keycloak dazwischen aus, bleibt ein halber Schritt übrig. CIAS wählt die Reihenfolge so, dass dieser halbe Schritt immer weniger Rechte übrig lässt, nie mehr: Beim Wegnehmen schreibt es zuerst in Keycloak, beim Geben zuerst in CIAS.
| Aufruf | Richtung | Antwort und was übrig bleibt |
|---|---|---|
| Rolle vergeben | gibt | 503. Die Vergabe steht in CIAS, im Token fehlt sie noch. Aufruf wiederholen. |
| Rolle entziehen | nimmt | 503. Nichts geändert, die Rolle gilt weiter. Aufruf wiederholen. |
| Konto sperren oder schließen | nimmt | 503. Nichts geändert. Aufruf wiederholen. |
| Konto wieder freischalten | gibt | 503. Der Datensatz ist aktiv, das Konto in Keycloak noch aus. Aufruf wiederholen. |
| Gruppe anlegen, Rollen oder Mitglieder hinzufügen | gibt | Erfolg. Die Gruppe steht als PENDING in CIAS, der Abgleich trägt sie später nach Keycloak. |
| Rollen oder Mitglieder aus einer Gruppe nehmen, Gruppe löschen | nimmt | 503. Nichts geändert. Aufruf wiederholen. |
| befristete Rolle läuft ab (Zeitgeber) | nimmt | Der Lauf überspringt die Vergabe und macht mit den anderen weiter. Der nächste Lauf versucht es erneut. |
Wiederholen ist in allen Fällen sicher. Eine zweite Vergabe derselben Rolle legt keinen zweiten Datensatz an, sondern schreibt die bestehende noch einmal nach Keycloak. Warum die Reihenfolge genau so ist: Die Schreibreihenfolge.
Bereitstellung gescheitert
Manche Vorgänge brauchen mehrere Schritte, und ein Ausfall kann sie in der Mitte treffen. CIAS lässt sie dann in einem Zustand stehen, von dem aus man neu ansetzen kann. Keiner dieser Zustände lässt jemanden arbeiten, der es nicht soll.
| Was scheitert | Zustand danach | Arbeitet schon jemand? | Wie es weitergeht |
|---|---|---|---|
| Bereitstellung einer Registrierung | Vorgang FAILED | nein | POST /cias/admin/registrations/{id}/retry, oder discard, wenn es keinen Sinn mehr hat |
| Einrichten eines neuen Mandanten | Mandant mit Rollout FAILED, Stellung PENDING, Antwort 502 | nein, das Tor lässt ihn nicht zu | POST /cias/admin/tenants/{id}/retry-provisioning |
| Einrichten bricht ab, ohne Rückmeldung | Rollout bleibt IN_PROGRESS | nein | der Abgleich setzt ihn nach der Frist auf FAILED, dann Neuversuch. Siehe Einen Mandanten anlegen und bereitstellen |
| Gruppe erreicht Keycloak nicht | Gruppe PENDING | die Rechte aus der Gruppe wirken noch nicht | Abgleich der Gruppen, siehe Abgleich mit Keycloak |
| Rollenabgleich beim Start erreicht Keycloak nicht | nichts geschrieben, Meldung im Log | – | Die Anwendung startet trotzdem. Später erneut abgleichen. |
Neustart während eines Ausfalls
Das Gedächtnis der Filterkette liegt nur im Speicher. Startet eine Anwendung neu, ist es leer:
- Ist CIAS noch weg, kennt das Mandanten-Tor keinen einzigen Mandanten und lehnt alle Anfragen mit Mandant ab, bis CIAS wieder antwortet.
- Ist Keycloak noch weg, muss jedes Token neu getauscht werden, und das geht nicht. Auch die Schlüssel für die Signaturprüfung fehlen.
Ein Neustart „zur Sicherheit“ macht einen Ausfall also schlimmer, nicht besser.