Worum es geht
Jede Person hat in Keycloak ein Konto: Adresse, Passwort, MFA, Sitzungen. Zusätzlich führt CIAS einen eigenen Benutzerdatensatz. Warum zwei?
- Keycloak ist für die Anmeldung zuständig. Was eine Person fachlich ist, zu welchem Mandanten sie gehört und ob sie gesperrt ist, gehört zu CIAS.
- Stünde alles nur in Keycloak, wäre ein Wechsel des IdP eine Datenmigration aller Benutzer.
- Ohne eigenen Datensatz gäbe es nach einer Registrierung nichts, was CIAS sperren, auflisten oder einem Mandanten zuordnen könnte.
Datensatz und Konto
flowchart LR
subgraph C["CIAS: cias_user"]
direction TB
c1["id (eigene UUID)"]
c2["externalUserId"]
c3["email, displayName"]
c4["status"]
c5["homeTenantKey"]
c6["attributes"]
end
subgraph K["Keycloak: Konto"]
direction TB
k1["id (sub im Token)"]
k2["username = email"]
k3["Passwort, MFA, Sitzungen"]
k4["enabled"]
k5["Profilattribute"]
end
c2 -- "verweist auf" --> k1
c4 -. "ACTIVE ↔ enabled" .-> k4
Die Felder
| Feld | Bedeutung |
|---|---|
id | eigene ID in CIAS, eine UUID. Alle anderen CIAS-Daten verweisen auf sie |
externalUserId | die ID des Kontos in Keycloak, im Token sub. Eindeutig |
email | die Adresse und zugleich der Login. Immer klein geschrieben gespeichert, eindeutig, nicht änderbar |
displayName | Anzeigename. Fehlt er, steht die Adresse da |
status | PENDING, ACTIVE, SUSPENDED oder CLOSED, siehe Der Lebenslauf eines Benutzers |
homeTenantKey | der Heimatmandant, oder leer in einer Installation ohne Mandanten |
attributes | fachliche Notizen als Schlüssel-Wert-Paare, siehe Attribute einer Person pflegen |
Der Datensatz liegt in der System-Datenbank, nie in der Datenbank eines Mandanten.
Der Heimatmandant ist ein Mandant. Weitere Mandanten, in denen die Person Mitglied ist, führt CIAS nicht am Datensatz. Sie stehen in Keycloak und kommen über das Token.
Was nie darin steht
Kein Passwort, kein Passwort-Hash, kein MFA-Geheimnis, kein Wiederherstellungscode, kein Token. Ein automatischer Architekturtest verhindert sogar, dass jemand ein Feld mit einem solchen Namen anlegt. Deshalb kann man den Datensatz gefahrlos sichern, kopieren und im Support lesen.
Wie ein Datensatz entsteht
Wann: Eine Registrierung wird abgeschlossen.
Am Ende der Bereitstellung legt ein Hook den Datensatz an: Adresse, Name aus Vor- und Nachname, Mandant aus der Registrierung, die übrigen Formularfelder als Attribute. Danach setzt er ihn auf ACTIVE. Gibt es zum Konto schon einen Datensatz, bleibt dieser, wie er ist.
Ergebnis: Siehe Was beim Abschluss passiert.
Wann: In Keycloak gibt es Konten, die CIAS noch nicht kennt.
Ein Plattform-Administrator startet die Übernahme. CIAS legt für jedes unbekannte Konto einen Datensatz an.
Ergebnis: Siehe Bestehende Konten übernehmen.
Einen Endpunkt „Benutzer von Hand anlegen“ gibt es nicht. Neue Personen kommen über die Registrierung.
Abfragen für Administratoren
Alle Endpunkte liegen unter /cias/admin/users und sind nur für Plattform-Administratoren.
| Aufruf | Ergebnis |
|---|---|
GET /cias/admin/users/page?query=&page=0&size=50 | Seite mit items, page, size, total, hasMore. query sucht in Adresse und Anzeigename, ohne Groß/Klein |
GET /cias/admin/users?tenantKey=nordbau | alle Personen mit diesem Heimatmandanten, nach Adresse sortiert. Ohne tenantKey: alle Personen ohne Mandant |
GET /cias/admin/users/by-email?email=… | eine Person oder 404 |
GET /cias/admin/users/{id} | eine Person |
GET /cias/admin/users/3f0c…{
"id": "3f0c…",
"externalUserId": "7f3c…",
"email": "anna@nordbau.example",
"displayName": "Anna Berg",
"status": "ACTIVE",
"homeTenantKey": "nordbau",
"attributes": { "department": "Einkauf" }
}Fehler kommen als { "error": "cias.user.…", "message": "…" }. Fehlt die Rolle, antwortet CIAS mit 403 cias.user.administration-denied, unabhängig davon, ob es die Person gibt. Eine unbekannte ID ergibt 404 cias.user.not-found.