Worum es geht
Jedes Projekt hat eigene Regeln für die Registrierung: Nur Adressen bestimmter Firmen zulassen, den Mandanten nach der Domain wählen, einer Person zusätzliche Rollen geben. Damit dafür niemand den Code von CIAS ändern muss, gibt es zwei Arten von Einhängepunkten:
- Ein Hook läuft im Vorgang. Er darf Werte ändern oder den Vorgang ablehnen.
- Ein Event wird danach verschickt. Wer es empfängt, erfährt, was passiert ist, kann es aber nicht mehr ändern.
- Bean, die
RegistrationHookumsetzt - darf ablehnen (
RegistrationRejectedException→ 422) - darf Mandant, Startrollen, Mail ändern
- Reihenfolge über
getOrder(), kleiner zuerst
- Spring-
@EventListeneraufRegistrationEvent - kann nichts mehr verhindern
- enthält nie ein Token
- wird direkt nach dem Speichern verschickt
Die Hook-Punkte auf der Zeitachse
-
1Hook
onResolveTenant(context, decision)– Mandant ändern, nicht beiFROM_CALLER -
2Hook
beforeValidation(context)– vor der Prüfung der Felder -
3CIASprüft die Felder
-
4Hook
afterValidation(context)– der übliche Ort für ein Veto -
5Hook
beforeIdentityProvisioning/afterIdentityProvisioning– nur bei neuem Konto, um das Anlegen in Keycloak -
6Hook
beforeNotification(mail, context)– vor jeder Mail, darf die Mail ändern -
7Benutzer→CIASklickt den Link
-
8Hook
onVerified(context)– nach der Bestätigung -
9Hook
onAssignInitialRoles(context, roles)– Startrollen ändern -
10Hook
onCompleted(context)– am Ende der Bereitstellung -
11Hook
onFailed(context, error)– wenn die Bereitstellung scheitert -
12Hook
onCompensate(context, accountRemoved)– wenn ein Administrator den gescheiterten Vorgang verwirft; in umgekehrter Reihenfolge, bevor CIAS Mandant, Organisation und Konto zurückbaut
Alle Methoden haben eine leere Standardumsetzung. Ein Hook setzt nur die um, die er braucht.
Die Varianten
Wann: Nur Adressen von Partnerfirmen sollen sich registrieren dürfen.
Der Hook wirft in afterValidation eine RegistrationRejectedException mit eigenem Schlüssel. CIAS legt dann kein Konto an und speichert nichts.
Ergebnis: 422 { "error": "<eigener Schlüssel>", "message": "the registration was refused" }
Wann: Adressen mit @nordbau.example sollen immer in nordbau landen.
onResolveTenant gibt eine neue TenantDecision zurück, etwa JOIN_EXISTING mit Schlüssel nordbau, und einen Grund. null heißt: unverändert. Mehrere Hooks laufen der Reihe nach, jeder sieht das Ergebnis des vorigen.
Ergebnis: Siehe Woher der Mandant kommt.
Wann: Personen einer bestimmten Firma sollen zusätzlich report-read bekommen.
onAssignInitialRoles bekommt die Rollen aus dem Regelwerk und gibt eine neue Menge zurück. CIAS prüft danach, dass es jede Rolle gibt.
Ergebnis: Siehe Startrollen als Regelwerk.
Wann: Einladung durch eine Mandanten-Administratorin.
onResolveTenant wird gar nicht aufgerufen. Der Mandant aus dem Token der Einladenden lässt sich nicht umlenken.
Wann: Ein Datensatz in einem anderen System soll angelegt werden.
onCompleted läuft noch in der Bereitstellung. Wirft er eine Ausnahme, endet der Vorgang in FAILED, und retry führt ihn erneut aus. Soll ein Fehler dort die Registrierung nicht aufhalten, ist ein Event der bessere Ort.
Die Events
| Event | wird verschickt, wenn |
|---|---|
Initiated(id, flow) | eine Registrierung angenommen und die Mail verschickt ist |
Verified(id) | die Adresse bestätigt ist, per Klick oder von Hand |
Completed(id, externalUserId, tenantKey) | die Bereitstellung fertig ist |
Rejected(id, reason) | ein Administrator abgelehnt hat |
Failed(id, reason) | die Bereitstellung gescheitert ist |
Expired(id, state, identityRemoved) | ein Vorgang verfallen, ersetzt oder verworfen ist |
Events werden im selben Thread verschickt, direkt nachdem CIAS den neuen Zustand gespeichert hat. Ein Listener, der lange braucht, verzögert die Antwort. Das Audit von CIAS hört auf dieselben Events, siehe Eine Spur für alles.