CodamAIDocs
Themafertig

Den Mandanten zulassen (Mandanten-Tor)

Auflösen und Zulassen sind zwei Schritte. Wie das Tor fragt, 30 Sekunden merkt, bei Ausfall aus dem Gedächtnis antwortet und warum unbekannt und gesperrt gleich aussehen.

Ausprägungen
CIAS erreichbarCIAS weg, Mandant bekanntCIAS weg, Mandant unbekanntgesperrter MandantSperre wirkt bis zu einer TTL später

Worum es geht

Ist der Mandant einer Anfrage aufgelöst, steht fest, welcher Mandant gemeint ist. Ob dieser Mandant heute arbeiten darf, ist eine zweite Frage. Ein Kunde kann gesperrt sein, sein Vertrag kann abgelaufen sein, oder es gibt ihn gar nicht.

Diese zweite Frage stellt das Mandanten-Tor. Es sitzt in der Filterkette direkt hinter der Auflösung, also vor jedem Modul. Die Antwort kommt immer von CIAS, denn nur CIAS führt die Mandanten.

Der Weg durch die Filterkette

Vom Token zum zugelassenen Mandanten
  1. Filterkette
    Token prüfen
    Signatur und Ablauf gültig?
    ↳ nein 401
  2. Filterkette
    Auflösen
    genau ein Mandant, oder bewusst keiner?
    ↳ nein 403 cias.authentication.tenant-unresolved
  3. Mandanten-Tor
    Zulassen
    Wird dieser Mandant heute bedient?
    ↳ nein 403 cias.authentication.tenant-not-served
  4. Filterkette
    Wechsel
    Hat der Header tenant den Mandanten gewechselt? Dann das Tor für das Ziel noch einmal fragen
    ↳ nein 403 cias.authentication.tenant-not-served
  5. RequestContext mit einem zugelassenen Mandanten

Hat eine Anfrage keinen Mandanten, hat das Tor nichts zu fragen und lässt sie durch. Ob eine Anfrage ohne Mandanten zulässig ist, entscheidet eine andere Regel, siehe Die vier Ergebnisse.

Was „bedient“ heißt

CIAS antwortet mit ja, wenn der Mandant die Stellung ACTIVE hat und das heutige Datum in seinem Gültigkeitsfenster liegt. Alle anderen Fälle sind nein. Die Einzelheiten stehen unter Der Lebenslauf eines Mandanten.

Woher das Tor die Antwort holt

Das Tor fragt über eine Schnittstelle, den TenantLookupPort. Wie die Frage bei CIAS ankommt, hängt davon ab, ob CIAS im selben Prozess läuft:

sequenceDiagram
    participant F as Filterkette
    participant G as Mandanten-Tor
    participant L as CIAS im selben Prozess
    participant R as CIAS als eigener Dienst
    F->>G: Wird nordbau bedient?
    alt eingebettet (lookup: local)
        G->>L: Methodenaufruf
        L-->>G: bedient: ja
    else getrennt (lookup: remote)
        G->>R: GET /cias/lookup/tenants/nordbau (Dienst-Token)
        R-->>G: 200 {"key":"nordbau","served":true}
    end
    G-->>F: zugelassen
eingebettetgetrennt
Einstellung beim Fragendencodamai.cias.tenancy.lookup=localcodamai.cias.tenancy.lookup=remote plus codamai.cias.tenancy.client.base-url
WegMethodenaufrufHTTP-Anfrage mit einem Token des Dienstes
Gibt es den Mandanten nichtleere Antwort404
Wartezeitkeinehöchstens 2 Sekunden Verbindungsaufbau und 2 Sekunden Antwort, dann gilt CIAS als nicht erreichbar
Einstellung bei CIAS–codamai.cias.tenancy.lookup-rest=true und lookup-roles: welche Rollen fragen dürfen

lookup hat keinen Standard. Fehlt die Einstellung, startet die Anwendung nicht. Das ist Absicht: Ein Tor, das ohne Antwortgeber alles durchließe, wäre eine Lücke, die ein vergessener Eintrag öffnet.

Der Endpunkt für den getrennten Betrieb verrät nur zwei Dinge: den Schlüssel und ob er bedient wird. Kein Anzeigename, keine Daten, keine Stellung. Er hat eigene Rollen, getrennt von der Verwaltungs-API. Sonst hätte jeder CDMS-Knoten ein Token, mit dem er Kunden schließen könnte, nur um eine Ja-Nein-Frage zu stellen.

Das Tor merkt sich Antworten

Die Frage kommt bei jeder Anfrage, die Antwort ändert sich selten. Das Tor merkt sich deshalb jede Antwort, auch jedes Nein, für eine kurze Zeit: standardmäßig 30 Sekunden (codamai.cias.tenant-gate.ttl). Es merkt sich höchstens 10 000 Mandanten (codamai.cias.tenant-gate.max-entries).

Was das Tor antwortet
Gemerkte AntwortCIAS erreichbarCIAS sagtErgebnis
jünger als 30 s––die gemerkte Antwort, ohne zu fragen
keine oder älterjabedientzugelassen, merken
keine oder älterjanicht bedient403 tenant-not-served, merken
keine oder älterjaunbekannt403 tenant-not-served, merken
vorhanden, egal wie altnein–die gemerkte Antwort, auch wenn sie Nein war
keinenein–403 tenant-not-served

Die Regel bei einem Ausfall in einem Satz: Ein Ausfall von CIAS wirft niemanden hinaus, der schon gearbeitet hat, und lässt niemanden neu herein. „Weiter bedienen“ heißt dabei, die letzte Antwort zu behalten, nicht eine günstige anzunehmen. Ein Mandant, der zuletzt gesperrt war, bleibt während des Ausfalls gesperrt.

Als nicht erreichbar gilt jeder Fehler beim Fragen: Zeitüberschreitung, abgelehnte Verbindung, eine Antwort mit Fehlercode, eine unlesbare Antwort. Keiner davon ist sicherer als der andere, also werden alle gleich behandelt.

Unbekannt und gesperrt sehen gleich aus

Warum das Tor ablehnt

Wann: CIAS kennt nordbau, bedient ihn aber nicht.

Das Tor lehnt ab.

Ergebnis: 403 cias.authentication.tenant-not-served

Wann: CIAS kennt keinen Mandanten nordbau.

Das Tor lehnt ab, mit genau derselben Antwort.

Ergebnis: 403 cias.authentication.tenant-not-served

Wann: Im Token steht etwa Nordbau mit Großbuchstaben.

Das Tor fragt gar nicht erst und behandelt ihn wie einen unbekannten Mandanten.

Ergebnis: 403 cias.authentication.tenant-not-served

Wann: Die Frage scheitert, und für nordbau gibt es keine gemerkte Antwort.

Das Tor lehnt ab.

Ergebnis: 403 cias.authentication.tenant-not-served

Wann: Der Mandant ist zugelassen, aber die Werte der Person in diesem Mandanten lassen sich nicht lesen.

Die Filterkette lehnt ab, statt mit falschen oder leeren Werten weiterzumachen. Ein leerer Wert wäre nur ein * davon entfernt, einen Attributfilter abzuschalten.

Ergebnis: 403 cias.authentication.tenant-not-served

Alle Ablehnungen tragen denselben Schlüssel. Das ist Absicht: Würde die Antwort verraten, ob es einen Mandanten gibt, könnte jeder mit einem gültigen Token Firmennamen durchprobieren und so die Kundenliste abfragen. Den genauen Grund findest du im Log der Anwendung. Mehr dazu unter Ablehnungen, die nichts verraten.

Eine Sperre wirkt mit Verzögerung

sequenceDiagram
    participant A as Admin
    participant C as CIAS
    participant G as Mandanten-Tor
    participant K as Client von nordbau
    K->>G: Anfrage (0 s)
    G->>C: Wird nordbau bedient?
    C-->>G: ja, gemerkt für 30 s
    A->>C: nordbau sperren (10 s)
    K->>G: Anfrage (20 s)
    G-->>K: gemerkt: ja, läuft weiter
    K->>G: Anfrage (35 s)
    G->>C: Wird nordbau bedient?
    C-->>G: nein
    G-->>K: 403 tenant-not-served

Eine Sperre wirkt also spätestens nach der eingestellten Zeit, in beiden Betriebsarten. Umgekehrt gilt dasselbe: Hat das Tor eben „unbekannt“ gemerkt und legt jemand den Mandanten gerade jetzt an, wird er erst nach Ablauf der Zeit zugelassen.

Die Zeit ist deshalb eine Sicherheitseinstellung, nicht nur eine Leistungsfrage. Länger heißt: weniger Rückfragen, aber auch länger arbeitende gesperrte Kunden.

Fallen

Weiter

Quellen im Code und in der Wissensdatenbank
  • CIAS/cias-authentication – TenantGate (admit, Cache, Ausfallregel, remember, invalidate), TenantGateProperties (codamai.cias.tenant-gate.ttl 30s, max-entries 10000), TenantAdmission (ADMITTED, NOT_SERVED, UNKNOWN, LOOKUP_UNAVAILABLE), TokenParser.admit, RequestAdmission.TENANT_NOT_SERVED
  • CIAS/cias-kernel – TenantLookupPort, TenantStanding, TenantKey.isValid
  • CIAS/cias-tenancy – LocalTenantLookupAdapter, TenantService.standing, Tenant.isServedOn, TenantLookupController (GET /cias/lookup/tenants/{key}), TenantLookupRoles, CiasTenancyConfiguration (lookup, lookup-rest)
  • CIAS/cias-tenancy-client – RemoteTenantLookupAdapter, CiasTenancyClientProperties (base-url, token, connect-timeout 2s, request-timeout 2s)
  • CIAS/cias-authentication/docs/adr – ADR-021; CIAS/cias-kernel/docs/adr – ADR-022
Suchen