Module melden ihre Rollen an

Worum es geht

CIAS erfindet keine Rollen. Jedes Modul weiß selbst am besten, welche Rechte es braucht, und meldet sie an: CDMS zum Beispiel eine Rolle je Modell und Operation, CIAS selbst tenant-admin, tenant-owner und tenant-user. Diese Anmeldung heißt Deklaration. Sie enthält zwei Listen: die Rollen des Moduls und die Benutzerattribute, die es braucht.

Was ein Modul angibt

Jedes Modul, das Rollen hat, stellt eine Bean vom Typ IdentityRegistryInterface bereit. In einem generierten CDMS-Projekt schreibt der Generator sie aus den Modellen.

GET /cias/fetch
Authorization: Bearer <Token mit declaration-reader>

{
  "roles": [
    { "key": "order-read", "group": "order", "name": "Aufträge lesen" },
    { "key": "order-edit", "group": "order", "name": "Aufträge bearbeiten" }
  ],
  "attributes": [
    { "key": "areas", "multivalued": true, "required": false, … }
  ]
}

Was ein Modul nicht angibt: den Client, den Scope, die Delegation. Diese drei legt die Installation fest.

Wie CIAS die Deklaration liest

Die Installation nennt jedes Modul in ihrer Konfiguration, mit Namen und Client, und sagt, wie es zu erreichen ist:

Der Name eines Moduls ist wichtig: Er sagt, wem eine Rolle gehört. Ein Client kann mehrere Module tragen, etwa ein Backend mit eingebettetem CDMS und CIAS. Ohne Namen würde das Schweigen eines Moduls die Rollen eines anderen stilllegen. Der Name muss eindeutig sein und darf sich zwischen zwei Läufen nicht ändern: Ein umbenanntes Modul sähe aus wie eines, das alle Rollen zurückzieht, und ein neues, das sie anmeldet.

Warum nur 200 zählt: Eine 404 hieße, dass der Endpunkt nicht dort ist, wo die Konfiguration sagt. Würde CIAS das als „meldet nichts an“ lesen, legte der nächste Abgleich alle Rollen dieses Moduls still, nur wegen eines Tippfehlers.

Was aus einer angemeldeten Rolle wird

Die Delegation einer neuen Rolle kommt aus der Installation, nicht aus der Deklaration. Ein Modul darf nicht bestimmen, wer seine Rollen weitergibt. Steht zu einer Rolle nichts in der Konfiguration, darf nur ein Plattform-Administrator sie vergeben. Das eigenständige CIAS legt zum Beispiel fest, dass tenant-user auch ein tenant-admin vergeben darf. Diese Startbelegung wird nur beim ersten Eintrag geschrieben. Ändert ein Administrator sie später, stellt kein Abgleich die alte wieder her.

Keine Plattformrollen aus einer Deklaration

Jede angemeldete Rolle wird eine Client-Rolle mit Scope TENANT. Das Format hat gar kein Feld für eine Plattformrolle, und das ist Absicht:

• Eine Realm-Rolle gilt in allen Modulen. Ein Modul könnte die Folgen einer solchen Rolle nicht überblicken.
• Eine Client-Rolle mit Scope PLATFORM gälte nur für Personen in statischen Mandanten und verschwände bei Personen in dynamischen Mandanten. Das wäre keine Plattformrolle, siehe Realm-Rolle, Client-Rolle, Organisationsrolle.

Plattformrollen kommen deshalb nur aus der Konfiguration der Installation, siehe Die Realm-Rollen der Plattform.

Wenn CIAS eine Deklaration nicht annimmt

Warum der Attributwiderspruch alles anhält, eine Schlüsselkollision aber nur einen Client: Ein Client ist ein eigener Namensraum. Zwei gleiche Rollennamen auf einem Client betreffen nur diesen Client. Die Benutzerattribute dagegen bilden ein Dokument für den ganzen Realm. Zwei Module, die ein Feld verschieden beschreiben, beschreiben dasselbe Feld, und wer zuletzt schriebe, gewönne.

Zwei Module, die ein Attribut gleich beschreiben, sind kein Widerspruch. Beide dürfen es anmelden.

Eine abgelehnte Deklaration hält CIAS nie an, weder beim Start noch sonst. CIAS ist das, woran sich alle anmelden. Würde der Fehler eines Moduls CIAS stoppen, wäre auch der Weg versperrt, ihn zu beheben. Der Bericht des Abgleichs nennt Modul, Attribut und verletzte Regel.

Fallen

Weiter

• Der Abgleich mit Keycloak
• Der Rollenkatalog
• Beide Module zusammen: Module melden Rollen und Attribute an