Worum es geht
Anna arbeitet für zwei Mandanten: nordbau und suedlogistik. In nordbau ist sie für die Region Nord zuständig, in suedlogistik für Süd. Ein einziger Wert region am Konto kann das nicht ausdrücken. Welchen Wert soll er haben?
Deshalb sagt jedes Attribut bei der Anmeldung, worüber es etwas aussagt:
| Bindung | bedeutet | Beispiele | Wo der Wert liegt |
|---|---|---|---|
USER | ein Wert pro Person, in jedem Mandanten derselbe | Sprache, Personalnummer, Anzeigename | am Konto in Keycloak, kommt über das Token |
USER_IN_TENANT | ein Wert je Person und Mandant | Regionen, Werke, Kostenstellen | in CIAS, je Person und Mandant |
Wie ein Attribut pro Mandant wird
Das Modul sagt es bei der Anmeldung, siehe Attribute anmelden:
Attribute.optional("region").asMultivalued().perTenant()Nur das anmeldende Modul weiß, was es meint: CIAS sieht, dass ein Attribut region heißt, aber nicht, ob eine Installation einer Person in zwei Mandanten verschiedene Regionen gibt. Was CDMS aus dem Modell erzeugt, ist immer USER, siehe Zwei Herkünfte von Attributen. Ein Attribut pro Mandant schreibt ein Modul in seiner Anmeldung selbst.
Die Werte schreibst du über POST /cias/admin/users/{id}/tenant-attributes?tenantKey=…, geprüft durch Delegation und Obergrenze, siehe Wer ein Attribut schreiben darf. Das geht nur für Attribute, die im Katalog pro Mandant stehen. Ein USER-Attribut wie locale lehnt CIAS dort ab, auch für einen Plattform-Administrator.
Das Szenario
-
1Admin→CIASschreibt für Anna in
nordbau:region = [nord] -
2Admin→CIASschreibt für Anna in
suedlogistik:region = [sued] -
3Client→CDMSAnna fragt Aufträge ab, Mandant
nordbau -
4CIASprüft das Token, legt den Mandanten fest, holt Annas Werte für
nordbau -
5CDMSfiltert mit
region IN (nord) -
6Client→CDMSAnna wählt
suedlogistikund fragt erneut -
7CDMSfiltert mit
region IN (sued)Ergebnis: Dieselbe Person, dasselbe Token, je Mandant andere Zeilen
Vorher und nachher
flowchart LR
subgraph T["Im Token von Anna"]
TR["region: nord, sued<br/>(ein Wert fürs ganze Konto)"]
TL["locale: de"]
end
subgraph C["In CIAS, Mandant suedlogistik"]
CR["region: sued"]
end
subgraph E["Effektiv in suedlogistik"]
ER["region: sued"]
EL["locale: de"]
end
CR -- "ersetzt" --> ER
TL -- "unverändert" --> EL
TR -. "wird ersetzt" .-> ER
Der Wert aus CIAS ersetzt den Wert aus dem Token für diesen Schlüssel. Alle anderen Attribute, etwa locale, kommen unverändert aus dem Token. Das gilt auch dann, wenn CIAS für so einen Schlüssel doch eine Zeile im Mandanten führt: Ersetzt wird nur, was die Anwendung selbst mit perTenant() anmeldet. Würde CIAS mischen, wäre der Filter in einem Mandanten breiter als in jedem einzelnen, genau das soll verhindert werden.
Die Ausprägungen
Wann: Das Attribut ist ohne Bindung oder mit USER angemeldet.
CIAS nimmt den Wert aus dem Token, in jedem Mandanten denselben. Es gibt keine zusätzliche Abfrage.
Ergebnis: Wert aus dem Token
Wann: Das Attribut ist mit perTenant() angemeldet.
CIAS holt bei jeder Anfrage mit Mandant die Werte der Person in diesem Mandanten und setzt sie ein.
Ergebnis: Wert aus CIAS für den aktiven Mandanten
Wann: Die Person gehört genau einem Mandanten an.
Es gilt dasselbe wie bei mehreren: Der Wert kommt aus CIAS für diesen einen Mandanten. Der Unterschied zu USER zeigt sich erst, wenn ein zweiter Mandant dazukommt.
Ergebnis: Wert aus CIAS
Wann: Die Person ist Mitglied mehrerer Mandanten und wählt einen davon für die Anfrage.
Der Wert kommt für den gewählten Mandanten. Beim privilegierten Wechsel in einen Mandanten, in dem die Person nicht Mitglied ist, bestimmt CIAS die Werte vorher, für den Ausgangsmandanten, und sie gelten im Ziel weiter, wie die Rollen. Siehe Zwischen Mandanten wechseln.
Ergebnis: je Mandant ein eigener Wert
Wann: Die Abfrage der Werte scheitert.
Hat CIAS die Werte dieser Person in diesem Mandanten zwischengespeichert, gelten diese, auch wenn sie älter sind. Sonst lehnt CIAS die Anfrage ab. Ein Ausfall soll niemandem mehr Reichweite geben und niemandem nehmen, womit er schon gearbeitet hat.
Ergebnis: Pufferwert, oder 403 cias.authentication.tenant-not-served
Woher die Werte kommen
| Betriebsart | Was muss vorhanden sein | Abfrage |
|---|---|---|
| eingebettet | cias-user mit codamai.cias.user.persistence=jpa | Methodenaufruf im selben Programm |
| getrennt | cias-tenancy-client im Modul; im CIAS codamai.cias.user.lookup-rest=true und codamai.cias.user.lookup-roles mit der Rolle des abfragenden Dienstes | GET /cias/lookup/users/{sub}/attributes über HTTP |
| egal | ein Modul meldet ein Attribut pro Mandant an, aber nichts kann die Werte abfragen | die Anwendung startet nicht, die Meldung nennt die Attribute |
| getrennt | Endpunkt im CIAS nicht eingeschaltet oder Rolle fehlt | jede Anfrage mit Mandant wird abgelehnt: 403 cias.authentication.tenant-not-served |
Die Antwort merkt sich CIAS je Person und Mandant für 30 Sekunden, einstellbar mit codamai.cias.attribute-lookup.ttl. Die Zahl der gemerkten Paare begrenzt codamai.cias.attribute-lookup.max-entries. Die Abfrage kostet also höchstens einen Aufruf je Person, Mandant und halbe Minute. Eine Installation ohne Attribut pro Mandant fragt nie.
Eine Anfrage ohne Mandant, etwa in der Betriebsart SINGLE, hat keine Werte pro Mandant. Dort gilt der Wert aus dem Token.