Worum es geht
Jede Anfrage an CDMS läuft zuerst durch die Filterkette von CIAS. Die Filterkette ist ein Stück Code vor den Endpunkten. Sie liest das Token aus dem Header Authorization: Bearer <token>, prüft seine Signatur und seine Gültigkeit und legt fest, wer anfragt und in welchem Mandanten.
Die Stationen
-
FilterketteToken lesenSteht ein Token im Header
Authorization?↳ nein 403, ohne CDMS-Fehlerkörper -
FilterketteToken prüfenIst die Signatur echt, das Token nicht abgelaufen, vom eingestellten Issuer, ein Access-Token und für diese Anwendung ausgestellt?↳ nein 401 mit
WWW-Authenticate: Bearer error="invalid_token" -
CIASMandantLässt sich der Mandant bestimmen, und wird er hier bedient?↳ nein 403, im Feld
errorz. B.cias.authentication.tenant-unresolved -
CDMSRolleVerlangt die Operation eine Rolle, und hat die Person sie?↳ nein 403
missing-permission|<rolle> - CDMS führt die Anfrage aus, mit den Filtern der Zeilen-Ebene
Was die Filterkette im Einzelnen tut, steht unter Was bei jeder Anfrage mit dem Token passiert.
Entscheidungstabelle
| Token | Pfad | Rolle verlangt | Antwort |
|---|---|---|---|
| keins | Endpunkt eines Modells | – | 403 von der Filterkette |
| ungültig, abgelaufen, fremd signiert oder für einen anderen Client | jeder | – | 401 invalid_token |
| keins | offener Pfad, z. B. die öffentliche Registrierung | – | 200 |
| keins | /v3/api-docs, /swagger-ui | – | 401, verlangt Benutzer und Passwort |
| gültig | Endpunkt eines Modells | ja, aber nicht im Token | 403 missing-permission|<rolle> |
| gültig | Endpunkt eines Modells | nein (publicAccess) | erlaubt, für jede angemeldete Person |
Varianten
Wann: Die Anfrage hat keinen Header Authorization.
Die Filterkette kennt keine Person. Für jeden Endpunkt eines Modells antwortet sie mit 403. Der Körper ist keine CDMS-Fehlerantwort, es gibt also kein messageKey.
Ergebnis: Der Client muss sich zuerst anmelden.
Wann: Das Token ist abgelaufen, kaputt, mit einem fremden Schlüssel signiert, stammt von einem anderen Issuer, ist ein ID-Token oder wurde für einen anderen Client ausgestellt.
Die Filterkette prüft die Signatur gegen die Schlüssel des Realms, das Ablaufdatum, den Issuer, den Typ und ob das Token den Client der Anwendung nennt. Scheitert eine Prüfung, antwortet sie mit 401 und dem Header WWW-Authenticate: Bearer error="invalid_token". Das gilt auch für offene Pfade: Ein ungültiges Token wird nie als „kein Token“ behandelt. Siehe Was bei jeder Anfrage mit dem Token passiert.
Ergebnis: Der Client erneuert das Token und wiederholt die Anfrage. Siehe Token erneuern.
Wann: Pfade, die ohne Token erreichbar sind
Ohne Token erreichbar sind OPTIONS-Anfragen, die der Browser vor einer Anfrage an eine andere Adresse schickt, und Pfade, die ein Modul ausdrücklich veröffentlicht, etwa die öffentliche Registrierung. Die Beschreibung der Schnittstelle unter /v3/api-docs und die Swagger-Oberfläche unter /swagger-ui brauchen kein Token, aber eine eigene Anmeldung mit Benutzer und Passwort, die der Betreiber vergibt. Ohne eingerichtete Zugangsdaten antworten sie mit 401. Health und Metriken liegen auf einem eigenen Port, der nicht nach außen geht.
Ergebnis: Kein Endpunkt eines Modells ist ohne Token erreichbar.
Wann: In der Modelldatei steht am Endpunkt publicAccess: true.
CDMS verlangt für diese Operation keine Rolle. Das Token braucht es trotzdem: Die Filterkette läuft vorher. Jede Person mit gültigem Token darf die Operation ausführen, und die Filter der Zeilen-Ebene gelten weiter.
Ergebnis: „Öffentlich“ heißt hier: für jede angemeldete Person. Siehe Modellrollen.
Wann: GET /{id}/file?access_token=<token>
Ein Browser kann bei einem Link keinen Header mitschicken. Deshalb nimmt der Download das Token als Parameter in der URL. Es wird genauso geprüft wie im Header: ungültig → 401, Mandant nicht zulässig → 403, dann Lese- und Download-Rolle.
Ergebnis: Siehe Herunterladen.
Fallen
Wie es weitergeht
- Welche Rolle eine Operation verlangt: Modellrollen
- Die Ebenen nach dem Token: Die drei Ebenen im Überblick