Worum es geht
Ein Attributwert ist ein Recht. Hat Anna region = nord, sieht sie in CDMS die Daten des Nordens. Wer ihr sued dazuschreibt, erweitert ihre Sicht, ohne dass sich eine Rolle ändert. Deshalb fragt CIAS vor jedem Schreiben eines Werts pro Mandant zwei Dinge:
- Delegation: Darfst du dieses Attribut überhaupt schreiben?
- Obergrenze: Darfst du diesen Wert schreiben? Du vergibst nie mehr, als du selbst hast.
Welcher Speicher, welche Regel
Die Prüfung gilt für die Werte pro Mandant. Die anderen Speicher, siehe Attribute einer Person pflegen, schreibt nur ein Plattform-Administrator:
| Speicher | Aufruf | Wer darf |
|---|---|---|
| Werte pro Mandant | POST /cias/admin/users/{id}/tenant-attributes?tenantKey=… | Delegation und Obergrenze, wie auf dieser Seite |
| Profil in Keycloak | POST /cias/admin/users/{id}/profile-attributes | nur Plattform-Administratoren. Bei einer Vorliebe wie locale auch die Person selbst, in Keycloaks Kontoseite |
| CIAS-Attribute (Notizen) | POST /cias/admin/users/{id}/attributes | nur Plattform-Administratoren |
Die Prüfung der Reihe nach
-
CIASangemeldetHat die Anfrage ein gültiges Token?↳ nein 403
-
CIASKatalogHat ein Modul das Attribut angemeldet?↳ nein 403, auch für einen Plattform-Administrator
-
CIASBindungIst das Attribut pro Mandant angemeldet (
USER_IN_TENANT)?↳ nein 403, auch für einen Plattform-Administrator -
CIASPlattform-Administrator?ja → erlaubt, alle weiteren Prüfungen entfallen
-
CIASnoch angemeldetMeldet ein Modul das Attribut noch an, oder ist es zurückgezogen?↳ nein 403
-
CIASDelegationSteht eine Rolle des Aufrufers in
assignableBydes Attributs?↳ nein 403 -
CIASObergrenzeLiegt jeder Wert in dem, was der Aufrufer selbst in diesem Mandanten hat?↳ nein 403
- Werte werden geschrieben
CIAS prüft alle Attribute eines Aufrufs, bevor es eines schreibt. Fällt eines durch, bleibt alles, wie es war. Jede Ablehnung sieht gleich aus: 403 cias.user.administration-denied. Welches Attribut und welche Station, steht nur im Log.
Die Person selbst sucht CIAS erst nach der Prüfung. Wer abgelehnt wird, bekommt also immer 403, auch für eine id, die es nicht gibt, und erfährt so nicht, welche Personen existieren. 404 cias.user.not-found sieht nur, wer die Prüfung bestanden hat.
Die Delegation
Wer ein Attribut schreiben darf, sagt weder das Modul noch eine Oberfläche, sondern die Installation. Sie stellt dafür eine Bean DeclaredAttributeDelegation bereit: je Attribut die Rollen, deren Inhaber es schreiben dürfen.
@Bean
DeclaredAttributeDelegation attributeDelegation() {
return new DeclaredAttributeDelegation(Map.of("region", Set.of("tenant-admin")));
}Der Abgleich überträgt diese Angabe bei jedem Lauf in den Katalog. Du siehst sie im Feld assignableBy unter GET /cias/admin/attributes/{key}. Ändern lässt sie sich nur über die Bean, nicht über eine REST-Schnittstelle. Gibt es keine Bean, ist assignableBy überall leer, und nur Plattform-Administratoren schreiben Werte.
Die Obergrenze als Mengenbild
flowchart LR
subgraph A["Anna, tenant-admin in nordbau<br/>eigener Wert: region = nord, west"]
direction TB
N["nord"]
W["west"]
end
N -->|"darf vergeben"| OK1["Ben: region = nord"]
W -->|"darf vergeben"| OK2["Ben: region = nord, west"]
X["sued"] -. "nicht in Annas Wert" .-> NO1["Ben: region = sued → 403"]
S["*"] -. "mehr als alles Einzelne" .-> NO2["Ben: region = * → 403"]
Verglichen wird genau so, wie der Attributfilter die Werte liest: an Kommas getrennt, Leerzeichen abgeschnitten, doppelte zählen einmal, * heißt „alles“. Die vollständige Tabelle steht unter Die Obergrenze.
Dein eigener Wert ist dabei dein Wert pro Mandant in CIAS für genau diesen Mandanten. Ein Wert, der nur in deinem Profil steht, zählt nicht. Hast du im Mandanten keinen Wert, kannst du dort keinen vergeben.
Die Ausprägungen
Wann: Das Token trägt eine Rolle, die als Plattform-Administrator zählt.
Delegation und Obergrenze entfallen. Ein Plattform-Administrator hält jedes Recht, auch jeden Wert. Nur ein nicht angemeldetes Attribut und eines, das an die Person gebunden ist, darf auch er hier nicht schreiben.
Ergebnis: erlaubt, auch für zurückgezogene Attribute
Wann: region ist an tenant-admin delegiert, Anna ist tenant-admin.
Die Delegation stimmt. Jetzt entscheidet der Wert.
Ergebnis: weiter zur Obergrenze
Wann: Anna hat nord, west und schreibt Ben nord.
nord ist in Annas Wert enthalten.
Ergebnis: erlaubt
Wann: Anna hat nord, west und schreibt Ben nord, sued.
sued hat Anna nicht. Ein einziger Wert zu viel lehnt den ganzen Aufruf ab.
Ergebnis: 403, nichts geschrieben
Wann: Anna schreibt Ben *, oder Anna selbst hat *.
* schaltet den Filter ganz ab. Nur wer selbst * hat, darf * vergeben. Wer * hat, darf jeden Wert vergeben.
Ergebnis: mit eigenem *: erlaubt. Sonst 403
Wann: Das Attribut steht nicht im Katalog, oder kein Modul meldet es mehr an.
Nicht angemeldet: Niemand sagt, wer es schreiben darf, also niemand. Zurückgezogen: Die Delegation gehörte zu einer Anmeldung, die es nicht mehr gibt.
Ergebnis: 403. Zurückgezogene schreibt nur noch ein Plattform-Administrator
Wann: Das Attribut ist mit USER angemeldet, etwa locale oder tenant, und jemand will es als Wert pro Mandant schreiben.
Ein Wert pro Mandant ersetzt im Mandanten den Wert aus dem Token. Ein locale pro Mandant würde also überschreiben, was Keycloak über die Person sagt. Das ist keine Frage der Berechtigung, sondern der falsche Speicher. Solche Attribute pflegst du im Profil, siehe Attribute einer Person pflegen.
Ergebnis: 403, auch für einen Plattform-Administrator
Lesen
Werte pro Mandant lesen Plattform-Administratoren und Personen, deren eigener Mandant der abgefragte ist: GET /cias/admin/users/{id}/tenant-attributes?tenantKey=nordbau. Werte anderer Mandanten bleiben unlesbar. Wer Werte schreiben darf, muss sie auch sehen können, deshalb ist Lesen etwas lockerer als Schreiben.