Worum es geht
Damit ein Attributfilter in CDMS einen Wert lesen kann, muss der Wert eine lange Strecke zurücklegen: vom Konto in Keycloak über das Token bis in den RequestContext. Der RequestContext ist das Objekt, in dem CIAS für jede Anfrage festhält, wer anfragt, mit welchen Rollen und welchen Attributen.
Die Strecke
sequenceDiagram
participant M as Modul
participant C as CIAS
participant K as Keycloak
participant B as Browser/BFF
participant D as CDMS
M->>C: meldet region an (Deklaration)
C->>K: Profil: region erlaubt
C->>K: Client des Moduls: Mapper region → Claim region
Note over C,K: einmal, beim Abgleich
C->>K: Admin schreibt region = nord, west am Konto
B->>K: Anmelden oder Token erneuern
K-->>B: Token mit "region": ["nord", "west"]
B->>D: Anfrage mit Token
D->>C: Token prüfen (Filterkette)
C->>C: Claim region → Attribut, ggf. Wert pro Mandant einsetzen
C-->>D: RequestContext: effectiveUserAttributes.region = [nord, west]
D->>D: Attributfilter: region IN (nord, west)
Die Stationen
| Station | Was dort passiert | Wer sorgt dafür |
|---|---|---|
| Benutzerprofil | Keycloak speichert nur Attribute, die im Profil stehen. Dort steht auch, ob es eine Liste ist und wer es ändern darf | der Abgleich, aus der Anmeldung |
| Wert am Konto | der eigentliche Wert der Person | ein Administrator über POST /cias/admin/users/{id}/profile-attributes, bei einer Vorliebe auch die Person selbst |
| Claim-Mapper | ein Eintrag am Client, der sagt: „Lege das Attribut region als Claim region ins Token.“ Er gilt für Access-Token, ID-Token und UserInfo | der Abgleich, je Modul an dessen Client |
| Token | der Claim steht im Token. Bei einer Liste als JSON-Array, sonst als Text | Keycloak, bei jedem Anmelden und Erneuern |
| RequestContext | CIAS macht aus jedem übrigen Claim ein Attribut, immer als Liste von Texten. Ist das Attribut pro Mandant angemeldet, setzt CIAS den Wert des aktiven Mandanten ein | CIAS, bei jeder Anfrage |
| Filter | CDMS liest das Attribut aus effectiveUserAttributes | CDMS |
Der Mapper sitzt am Client des Moduls, also an dem Client, dessen Token das Modul prüft. Welche Claims CIAS überhaupt als Attribut nimmt und welche nicht, steht unter Was aus dem Token gelesen wird.
Die Ausprägungen
Wann: Attribut ohne multivalued, am Konto steht customerId = 4711.
Im Token steht "customerId": "4711". CIAS macht daraus eine Liste mit einem Eintrag.
Ergebnis: effectiveUserAttributes.customerId = ["4711"]
Wann: Attribut mit multivalued, am Konto stehen nord und west.
Im Token steht "region": ["nord", "west"]. Der Filter zerlegt zusätzlich jeden Eintrag an Kommas, nord,west in einem Eintrag wirkt also genauso.
Ergebnis: effectiveUserAttributes.region = ["nord", "west"]
Wann: Die Person hat keinen Wert, und das Attribut hat keinen Standardwert.
Keycloak lässt den Claim weg. Im RequestContext fehlt das Attribut. Ein Attributfilter in CDMS lehnt die Anfrage dann ab, statt alles zu liefern.
Ergebnis: 422 missing-attribute-on-profile bei einem gefilterten Modell
Wann: Das Attribut ist USER_IN_TENANT angemeldet.
Nach der Mandantenprüfung holt CIAS die Werte der Person für den aktiven Mandanten und setzt sie für diesen Schlüssel ein. Sie ersetzen den Wert aus dem Token, sie werden nicht dazugemischt. Ersetzt werden nur Schlüssel, die die Anwendung selbst pro Mandant anmeldet, alle anderen kommen unverändert aus dem Token.
Ergebnis: siehe Ein Wert pro Person oder pro Mandant
Wo es hängen kann
| Steht im Profil? | Mapper am Client? | Wert am Konto? | Neues Token geholt? | Ergebnis |
|---|---|---|---|---|
| nein | – | – | – | Keycloak nimmt keinen Wert an. Meldet ein Modul das Attribut an? Lief der Abgleich? |
| ja | nein | – | – | Wert steht am Konto, aber nicht im Token. Läuft das Modul mit dem richtigen Client? |
| ja | ja | nein | – | kein Claim, CDMS antwortet 422 |
| ja | ja | ja | nein | altes Token ohne den neuen Wert |
| ja | ja | ja | ja | kommt an |