Worum es geht
Gruppen verwaltest du über die Verwaltungs-API unter /cias/admin/groups. Die Oberflächen dafür rufen genau diese Aufrufe auf, siehe Die Verwaltungsoberfläche.
Die Aufrufe
| Aufruf | Tut |
|---|---|
GET /cias/admin/groups?query=…&page=0&size=50 | eine Seite Gruppen, sortiert nach Schlüssel. query sucht in Schlüssel, Name und Beschreibung |
GET /cias/admin/groups/{key} | eine Gruppe |
POST /cias/admin/groups | Gruppe anlegen |
PUT /cias/admin/groups/{key} | Name, Beschreibung, Rollen und Standardgruppe ändern |
DELETE /cias/admin/groups/{key} | Gruppe löschen |
GET /cias/admin/groups/{key}/members?page=0&size=50 | eine Seite Mitglieder, als IDs der Benutzerdatensätze |
POST /cias/admin/groups/{key}/members | Mitglieder aufnehmen |
POST /cias/admin/groups/{key}/members/remove | Mitglieder entfernen |
GET /cias/admin/groups/of-user/{userId} | alle Gruppen einer Person, ohne Seiten |
POST /cias/admin/groups/import | bestehende Keycloak-Gruppen übernehmen |
POST /cias/admin/groups/reconcile | Abgleich mit Keycloak starten, siehe Abgleich mit Keycloak |
Listen kommen immer in Seiten: items, page, size, total, hasMore. Ohne Angabe sind es 50 Zeilen, höchstens 500. Wer mehr verlangt, bekommt 400 statt still weniger Zeilen.
Die Prüfungen
-
CIASPlattform-AdministratorIst der Aufrufer angemeldet, und trägt sein Token eine Rolle, die als Plattform-Administrator zählt?↳ nein 403
cias.authorization.denied, Textnot permitted -
CIASGruppeGibt es die Gruppe (bei allem außer Anlegen)? Ist der Schlüssel noch frei (beim Anlegen)?↳ nein 404
cias.authorization.group-not-foundbzw. 409cias.authorization.group-key-in-use -
CIASRollenSteht jede genannte Rolle im Katalog?↳ nein 404
cias.authorization.role-not-found -
CIASKeycloakBeim Nehmen: Hat Keycloak die Änderung angenommen?↳ nein 503, CIAS bleibt unverändert
- Änderung gespeichert
Die 403 sieht genauso aus wie jede andere Ablehnung der Rechteprüfung. Den genauen Grund schreibt CIAS ins Log.
Eine Gruppe anlegen
POST /cias/admin/groups
Authorization: Bearer <Token eines Plattform-Administrators>
{
"key": "support",
"name": "Support 1st Level",
"description": "Alle im telefonischen Support",
"roles": [
{ "client": null, "key": "user" },
{ "client": "cdms-backend", "key": "customer-read" },
{ "client": "crms-backend", "key": "ticket-edit" }
],
"defaultGroup": false
}HTTP 200
{
"key": "support",
"name": "Support 1st Level",
"description": "Alle im telefonischen Support",
"roles": [
{ "client": null, "key": "user", "displayName": "Benutzer",
"scope": "PLATFORM", "effectiveInEveryTenant": true },
{ "client": "cdms-backend", "key": "customer-read", "displayName": "Kunden lesen",
"scope": "PLATFORM", "effectiveInEveryTenant": false },
{ "client": "crms-backend", "key": "ticket-edit", "displayName": "Tickets bearbeiten",
"scope": "TENANT", "effectiveInEveryTenant": false }
],
"memberCount": 0,
"defaultGroup": false,
"syncState": "SYNCHRONIZED"
}| Feld | Bedeutung |
|---|---|
key | Pflicht. Fest für immer, in Keycloak der Name der Gruppe |
name | optional, sonst der Schlüssel |
roles | die vollständige Liste. client: null ist eine Realm-Rolle. Fehlt die Liste, trägt die Gruppe keine Rollen |
defaultGroup | fehlt es, ist es false. Ein Client, der das Feld nicht kennt, macht so nie aus Versehen eine Standardgruppe |
effectiveInEveryTenant | true nur bei Realm-Rollen. false heißt: Diese Rolle fällt unter einem Mandanten mit eigenen Rollen weg, siehe Gruppenrollen unter dynamischen Mandanten |
syncState | SYNCHRONIZED, wenn die Kopie in Keycloak steht, sonst PENDING |
Eine frisch angelegte Gruppe hat noch keine Mitglieder. Sie gibt also noch niemandem etwas.
Die sechs Ausprägungen
Wann: POST /cias/admin/groups
-
1CIASprüft Schlüssel und Rollen, speichert die Gruppe als
PENDING -
2CIAS→Keycloaklegt die Gruppe im Realm an, markiert mit
cias-managed=true, setzt Rollen und Standardgruppe -
3CIASmerkt sich die Keycloak-ID, setzt
SYNCHRONIZEDErgebnis: 200 mit der Gruppe. Ist Keycloak nicht erreichbar, trotzdem 200, abersyncState: PENDING
Wann: PUT /cias/admin/groups/{key}, Pfad und key im Body müssen gleich sein, sonst 400
-
1CIAS→Keycloaknimmt zuerst weg: Rollen, die nicht mehr dabei sind, und ggf. die Eigenschaft Standardgruppe
-
2CIASspeichert Name, Beschreibung, Rollen, Standardgruppe, setzt
PENDING -
3CIAS→Keycloakgibt dann dazu: neue Rollen, ggf. Standardgruppe; setzt
SYNCHRONIZEDErgebnis: 200. Scheitert der erste Keycloak-Schritt: 503, nichts geändert. Scheitert der letzte: 200 mitPENDING
Wann: DELETE /cias/admin/groups/{key}
-
1CIAS→Keycloaklöscht die Kopie der Gruppe
-
2CIASlöscht Gruppe und MitgliedschaftenErgebnis: 204. Die Mitglieder behalten ihre Konten und verlieren nur, was die Gruppe gab. Scheitert Keycloak: 503, die Gruppe bleibt
Wann: POST …/members mit { "userIds": ["5c9e…", "7a1b…"] }
-
1CIASspeichert die Mitgliedschaften; wer schon Mitglied ist, bleibt es einfach
-
2CIAS→Keycloaknimmt jede Person in die Kopie der Gruppe aufErgebnis: 200 mit der Gruppe. Klappt Keycloak nicht für alle: trotzdem 200, aber
PENDING
Wann: POST …/members/remove mit { "userIds": ["5c9e…"] }
-
1CIAS→Keycloaknimmt jede Person aus der Kopie der Gruppe
-
2CIASlöscht die MitgliedschaftenErgebnis: 200. Scheitert Keycloak: 503, CIAS bleibt unverändert
Wann: POST /cias/admin/groups/import, ohne Body
Übernimmt die Gruppen, die es in Keycloak schon gibt und die CIAS noch nicht führt. Details im nächsten Abschnitt.
Ergebnis: 200 mit einem Bericht
Rollen ändern heißt: die ganze Liste schicken
Es gibt kein „Rolle hinzufügen“ und kein „Rolle entfernen“. Du schickst beim PUT immer die vollständige Liste. Eine Rolle entfernst du, indem du die Liste ohne sie schickst. Was du weglässt, fällt weg, auch in Keycloak, auch wenn es die letzte Rolle eines Moduls war.
Der Schlüssel lässt sich nicht ändern. Soll eine Gruppe anders heißen, änderst du name.
Mitglieder sind Benutzerdatensätze
userIds sind die IDs der Benutzerdatensätze in CIAS, nicht die Keycloak-sub. Wie du sie findest, steht unter Der Benutzerdatensatz. Die Liste darf nicht leer sein, sonst 400. Du kannst mehrere Personen auf einmal aufnehmen oder entfernen, wie beim Ankreuzen in einer Oberfläche.
Bestehende Keycloak-Gruppen übernehmen
Ein Realm, den es schon vor CIAS gab, enthält oft Gruppen, die jemand in der Keycloak-Konsole angelegt hat. Sie tragen keine Marke cias-managed, also fasst CIAS sie nicht an. Mit dem Import übernimmt CIAS sie.
-
1CIAS→Keycloakliest alle Gruppen der obersten Ebene ohne Marke
cias-managed. Gruppen, die Keycloak selbst führt (Attribute mitkc., etwa Organisationsgruppen), bleiben außen vor -
2CIASFührt CIAS schon eine Gruppe mit diesem Schlüssel? Dann bleibt sie unangetastet
-
3CIASStehen alle Rollen der Gruppe im Katalog? Hat jedes Mitglied einen Benutzerdatensatz in CIAS?
-
4CIASnein → Gruppe wird übersprungen, mit Grund im Bericht
-
5CIASspeichert die Gruppe mit Rollen, Mitgliedern und Standardgruppe, genau wie in Keycloak
-
6CIAS→Keycloaksetzt die Marke
cias-managed=true, sonst nichtsErgebnis: Die Gruppe gehört jetzt CIAS. Rollen und Mitglieder sind unverändert
POST /cias/admin/groups/importHTTP 200
{
"found": 4,
"adopted": 2,
"alreadyKnown": 1,
"skipped": [
{ "group": "buchhaltung",
"reason": "it carries 1 role(s) the CIAS catalogue does not know (erp:invoice-approve) — their module has to declare them first, or the next reconciliation would take them off the group" }
]
}Eine Gruppe wird ganz oder gar nicht übernommen. Warum so streng? Was CIAS führt, schreibt der Abgleich später nach Keycloak zurück. Würde CIAS eine unbekannte Rolle einfach weglassen, nähme der nächste Abgleich sie der Gruppe weg. Würde CIAS ein unbekanntes Mitglied weglassen, flöge die Person aus der Gruppe. Deshalb: erst fehlende Rollen vom Modul anmelden lassen und fehlende Konten übernehmen, dann den Import wiederholen.
Der Import lässt sich gefahrlos wiederholen. Übernommene Gruppen tragen die Marke und tauchen beim nächsten Lauf nicht mehr auf. Ein unterbrochener Lauf wird beim nächsten Mal zu Ende gebracht. Unter alreadyKnown zählen Keycloak-Gruppen ohne Marke, deren Namen CIAS schon für eine eigene Gruppe führt. Sie bleiben unangetastet. Untergruppen übernimmt der Import nicht, nur die oberste Ebene.
Fehler auf einen Blick
| Antwort | Wann |
|---|---|
400 cias.authorization.invalid-request | key fehlt, userIds leer, Pfad und Body nennen verschiedene Gruppen, Leerzeichen in einem Rollennamen, Seite zu groß |
403 cias.authorization.denied | kein Plattform-Administrator |
404 cias.authorization.group-not-found | Gruppe unbekannt. GET /cias/admin/groups/{key} antwortet 404 ohne Body |
404 cias.authorization.role-not-found | eine Rolle steht nicht im Katalog |
409 cias.authorization.group-key-in-use | der Schlüssel ist schon vergeben |
| 503 | Keycloak nicht erreichbar, beim Nehmen |