Worum es geht
Ein Token ist ein kleines, signiertes JSON-Dokument. Es sagt, wer jemand ist und was für ihn gilt. Auf dem Weg einer Anfrage wechselt es mehrfach den Besitzer, wird einmal getauscht und am Ende gar nicht mehr gebraucht.
Diese Seite verfolgt es von der Anmeldung bis zu der Stelle, an der CDMS Daten liest. Wie derselbe Weg fachlich aussieht, steht unter Von der Anmeldung bis zu den Daten.
Zwei Wörter vorweg:
- Ein BFF („Backend for Frontend“) ist der kleine Server, der zu einem Portal gehört. Der Browser redet mit ihm, er redet mit der API.
- Die Filterkette ist Code aus
cias-authentication, der vor jedem Endpunkt läuft. Sie steckt in beiden Betriebsarten im CDMS-Prozess, auch wenn CIAS ein eigener Dienst ist.
Die Stationen
-
KeycloakAusstellenStimmen die Anmeldedaten? Dann gibt es Access-, Refresh- und ID-Token↳ nein kein Token – die Anmeldung scheitert
-
BFFAufbewahrenDie drei Tokens wandern in ein verschlüsseltes Sitzungs-Cookie. Der Browser bekommt nur dieses Cookie
-
ClientMitschickenDer BFF entschlüsselt das Cookie und hängt das Access-Token als
Authorization: Bearer …an den API-Aufruf↳ nein 403 – auf jedem geschützten Pfad ohne Token -
FilterkettePrüfenSignatur gegen einen öffentlichen Schlüssel des Realms, dazu Beginn und Ablauf. Keycloak wird dafür nicht gefragt↳ nein 401 mit
WWW-Authenticate: Bearer error="invalid_token" -
FilterketteTauschenKeycloak tauscht das Token gegen eines für den eigenen Client von CIAS↳ nein die Anfrage läuft ohne Identität weiter, jede Rollenprüfung lehnt danach ab
-
FilterketteLesenAus dem getauschten Token: Benutzer, Name, Realm-Rollen, Fachrollen, Gruppen, Organisationen, Attribute
-
CIASErgänzenMandant auflösen, Mandanten-Tor fragen, Rollen und Attribute für genau diesen Mandanten bilden↳ nein 403 mit einem Schlüssel
cias.authentication.… -
FilterketteAblegenAlles zusammen kommt in den RequestContext dieser einen Anfrage
- CDMS arbeitet – und liest nur noch den RequestContext
Jede einzelne Station hat eine eigene Seite. Diese hier zeigt nur, dass es eine Kette ist: Token prüfen, Token tauschen, Claims lesen, Mandant auflösen, Mandant zulassen, Effektive Rollen bilden.
Wo welches Token liegt
Auf einem Anfrageweg sind mehrere Tokens unterwegs, und sie gehören verschiedenen Beteiligten.
| Token | Wer stellt es aus | Wo liegt es | Wer benutzt es |
|---|---|---|---|
| Access-Token des Benutzers | Keycloak | im Sitzungs-Cookie des BFF | der BFF, bei jedem API-Aufruf |
| Refresh-Token | Keycloak | nur im Sitzungs-Cookie | der BFF, um ein neues Access-Token zu holen |
| ID-Token | Keycloak | nur im Sitzungs-Cookie | der BFF beim Abmelden |
| getauschtes Token | Keycloak, auf Bitte von CIAS | im Speicher des CDMS-Prozesses, höchstens 5 Minuten | die Filterkette, um Rollen und Attribute zu lesen |
| Dienst-Token für die Lookups | Keycloak, für den eigenen Client des CDMS-Dienstes (Client Credentials) | im Speicher des CDMS-Dienstes, erneuert nach drei Vierteln der Laufzeit | cias-tenancy-client, um CIAS über HTTP zu fragen |
| Leser-Token für die Deklaration | Keycloak, für den Leser-Client von CIAS (Client Credentials) | im Speicher des CIAS-Dienstes, erneuert nach drei Vierteln der Laufzeit | CIAS, um GET /cias/fetch bei CDMS zu lesen |
Der Browser hält kein Token, sondern nur das verschlüsselte Cookie. Warum das so ist, steht unter Sitzung im BFF und Cookies.
Die vier Wege im Einzelnen
Wann: Der Normalfall – jemand klickt in Hub, CDMS-Portal oder CIAS-Portal.
-
1Browser→BFFKlick, das Sitzungs-Cookie geht automatisch mit
-
2BFFentschlüsselt das Cookie und nimmt das Access-Token herausFehlt es oder steht ein Fehler in der Sitzung, antwortet der BFF selbst mit 401 und das Portal startet einen neuen Login
-
3BFF→CDMS
POST /api/rest/crm/customer/querymitAuthorization: Bearer … -
4CDMS→BFFAntwortErgebnis: Der BFF reicht die Daten an den Browser weiter
Wann: Ein Browser folgt einem Link, ein <img src> lädt ein Bild, ein PDF-Betrachter holt eine Datei.
Keiner dieser Fälle kann einen eigenen Header setzen. Deshalb nehmen die Download-Endpunkte das Token als ?access_token= in der Adresse. Geprüft wird es genauso: Signatur und Ablauf. Die Identität liest aber nicht die Filterkette, sondern der Endpunkt selbst – mit denselben Schritten ab „Tauschen“.
Ergebnis: Lehnt CIAS dabei ab, endet der Download mit derselben Ablehnung wie jede andere Anfrage. Siehe Zugriff ohne Token.
Wann: CIAS läuft als eigener Dienst, und der CDMS-Dienst muss etwas wissen.
-
1CDMSnimmt sein Dienst-Token – geholt bei Keycloak mit Client-ID und Secret des Dienstes (Client Credentials), rechtzeitig vor dem Ablauf erneuert
-
2CDMS→CIAS
GET /cias/lookup/tenants/{key}undGET /cias/lookup/users/{id}/attributes?tenantKey=… -
3CIASprüft die Rolle des Aufrufers – je Endpunkt eine eigene, ohne Standardwert
-
4CIAS→CDMSAntwortErgebnis: Der CDMS-Dienst merkt sie sich für die eingestellte Zeit
Wann: CIAS holt sich die Liste der Rollen und Attribute eines Moduls.
Die Richtung ist umgekehrt: CIAS ruft CDMS auf, GET /cias/fetch, mit einem eigenen Leser-Token, das CIAS genauso bei Keycloak holt. Die Antwort ist die komplette Rechtekarte der Anwendung, also nichts, was öffentlich sein dürfte. CDMS prüft dafür eine eigene Realm-Rolle.
Ergebnis: Dieser Aufruf liegt nicht auf dem Anfrageweg. Er läuft beim Start und wenn jemand den Abgleich anstößt. Siehe Module melden ihre Rollen an.
Was am Ende im RequestContext steht
Der RequestContext ist der einzige Ort, an dem CDMS nachliest. Er enthält unter anderem:
| Feld | Woher | Wofür |
|---|---|---|
userId | sub aus dem getauschten Token | Eigentümer neuer Objekte, Historie, Owner-Filter |
userName | name, sonst preferred_username | Anzeige und Protokoll |
userTenant | aufgelöster und zugelassener Mandant | Welche Datenbank, welche Zeilen |
allowedTenants | eigener Mandant, Organisationen, Attribut | Was ein Mandantenwechsel erreichen darf |
effectiveUserRealmRoles | realm_access.roles | Plattformrollen, Wechselrechte |
effectiveUserRoles | Fachrollen für den aktiven Mandanten | Modell- und Feldrollen in CDMS |
effectiveUserGroups | groups | zur Information |
effectiveUserAttributes | Token plus Werte pro Mandant | Attributfilter auf Zeilen |
Welcher Claim genau wohin geht, steht unter Was aus dem Token gelesen wird.
Wer den RequestContext liest
-
1CDMSDie Rechteprüfung vergleicht die Fachrollen mit den Rollen, die das Modell verlangtSiehe Modellrollen und Feldrollen.
-
2CDMSDer Attributfilter nimmt einen Attributwert der Person und schränkt damit die Zeilen einSiehe Attributfilter.
-
3CDMSDer Owner-Filter vergleicht
_userIdder Zeile mit deruserIdder AnfrageSiehe Nur eigene Daten. -
4CDMSBeim Schreiben trägt der System-Layer die
userIdals Eigentümer ein, die Historie schreibt sie mit -
5CDMSDie Dateiablage legt Dateien unter dem Mandanten der Anfrage ab
-
6CIASDie eigenen Endpunkte von CIAS lesen denselben Kontext als Aufrufer: authentifiziert, Mandant, Rollen, PersonErgebnis: Ein Mandantenadministrator verwaltet damit immer seinen eigenen Mandanten, nie einen aus dem Anfragekörper
Nach der Antwort ist alles weg
Die Filterkette räumt den RequestContext am Ende jeder Anfrage wieder ab – auch dann, wenn die Anfrage abgelehnt wurde. Das ist nötig, weil der Kontext am Thread hängt und Threads wiederverwendet werden. Bliebe er stehen, könnte die nächste Arbeit auf demselben Thread Identität, Mandant und Rollen der vorigen Anfrage lesen.