CodamAIDocs
Themafertig

Was beim Abschluss passiert

Die Bereitstellung in fester Reihenfolge: Startrollen bestimmen, Konto freischalten, Mandant anlegen oder zuordnen, Rollen vergeben, Willkommensmail.

Ausprägungen
neuer Mandantbestehender Mandant (statisch)bestehender Mandant (dynamisch)ohne MandantFehler → FAILED

Worum es geht

Ist die Adresse bestätigt und, falls nötig, die Registrierung genehmigt, beginnt die Bereitstellung. Erst jetzt entsteht, was die Person zum Arbeiten braucht: freigeschaltetes Konto, Mandant, Mitgliedschaft, Rollen. Am Ende steht die Willkommensmail.

Die Schritte

Bereitstellung (Zustand PROVISIONING)
  1. 1
    CIAS
    bestimmt die Startrollen aus dem Regelwerk, danach dürfen Hooks sie ändern (onAssignInitialRoles)
  2. 2
    CIAS→Keycloak
    prüft, dass es jede dieser Rollen gibt
    fehlt eine: FAILED
  3. 3
    CIAS→Keycloak
    nur bei neuem Konto: Adresse als bestätigt markieren, Konto freischalten, „Passwort setzen“ verlangen
  4. 4
    CIAS→Keycloak
    Mandant: neu anlegen oder bestehenden zuordnen, siehe unten
  5. 5
    CIAS→Keycloak
    Startrollen vergeben, im Mandanten oder global
  6. 6
    Hook
    onCompleted: CIAS legt den Benutzerdatensatz an und trägt die Person in Standardgruppen ein, dazu eigene Hooks
  7. 7
    CIAS
    Vorgang → COMPLETED
  8. 8
    CIAS→E-Mail
    Willkommensmail, bei neuem Konto möglichst mit Link zum Passwort-Setzen
    Ergebnis: Die Person kann sich anmelden

Die Willkommensmail ist der letzte Schritt. Scheitert nur sie, ist die Registrierung trotzdem abgeschlossen.

Der Mandant in den Varianten

Wie die Person zu ihrem Mandanten kommt

Wann: Zuordnung CREATE_NEW, etwa bei der Selbstregistrierung.

  1. 1
    CIAS→Keycloak
    legt die Organisation an: Alias = Mandantenschlüssel, Name = Feld company
  2. 2
    CIAS
    legt den Mandanten an, Art DYNAMIC, mit Verweis auf die Organisation. Bei MULTI wird dabei auch die Datenbank des Mandanten bereitgestellt
  3. 3
    CIAS→Keycloak
    macht die Person zum Mitglied der Organisation
  4. 4
    CIAS→Keycloak
    setzt die Attribute tenant und allowedTenants am Konto

Ergebnis: Die Person ist Gründerin des neuen Mandanten. Rollen der Situation TENANT_FOUNDER.

Wann: Der Mandant hat keine Organisation.

CIAS setzt die Attribute tenant und allowedTenants am Konto. Mehr braucht es nicht: Bei einem statischen Mandanten ist das Attribut die Mitgliedschaft. Die Rollen werden global vergeben.

Ergebnis: Rollen der Situation TENANT_MEMBER.

Wann: Der Mandant hat eine Organisation in Keycloak.

CIAS setzt die Attribute und macht die Person zum Mitglied der Organisation. Die Rollen werden in der Organisation vergeben und landen damit im Organisations-Claim des Tokens.

Ergebnis: Rollen der Situation TENANT_MEMBER.

Wann: Zuordnung NONE.

Kein Mandant, keine Mitgliedschaft. Die Rollen werden global vergeben.

Ergebnis: Rollen der Situation TENANTLESS.

Ob es einen bestehenden Mandanten gibt, prüft CIAS in diesem Schritt. Gibt es ihn nicht, endet der Vorgang in FAILED.

Wenn etwas schiefgeht

Fehler in der Bereitstellung
Was scheitert?Folge
eine Startrolle gibt es nichtFAILED. Rolle anlegen, dann retry
Keycloak nicht erreichbarFAILED, Antwort 503. Später retry
der genannte Mandant existiert nichtFAILED. Mandant anlegen oder Vorgang verwerfen
ein eigener Hook wirft eine AusnahmeFAILED. Ursache beheben, dann retry
eine Regel für die Startrollen lässt sich nicht auswertenFAILED. Regel reparieren, dann retry
der Mandantenschlüssel gehört inzwischen einem anderen MandantenFAILED, Antwort 422 cias.registration.tenant-key-taken. Vorgang verwerfen
nur die WillkommensmailCOMPLETED, die Mail fehlt

Bei FAILED bekommt die Anfrage, die die Bereitstellung ausgelöst hat, einen Fehler: der Klick auf den Link oder die Genehmigung. Die Person selbst bekommt keine Mail. Ein Plattform-Administrator findet den Vorgang in der Liste mit state=FAILED und kann ihn mit retry wiederholen oder mit discard verwerfen. Siehe Freigabe durch einen Administrator.

Neuer Mandant: Wiederholen und Zurückbauen

Beim Anlegen eines neuen Mandanten (CREATE_NEW) entstehen Dinge, die ein zweiter Versuch schon vorfindet. Deshalb merkt sich der Vorgang die Organisation, die er in Keycloak angelegt hat, sobald sie existiert.

  • retry macht weiter. Er nimmt die gemerkte Organisation und den Mandanten, der daran hängt, statt beide ein zweites Mal anzulegen. Ist nur die Bereitstellung des Mandanten gescheitert, stößt er sie erneut an.
  • Fremdes wird nie übernommen. Der Mandantenschlüssel wird bei der Registrierung geprüft, aber nicht reserviert. Liegt unter ihm inzwischen eine Organisation, die der Vorgang nicht selbst angelegt hat, lehnt retry ab. Sonst würde die Gründerin Inhaberin eines fremden Mandanten.
  • discard baut zurück. Siehe Aufräumen.

Weiter

Quellen im Code und in der Wissensdatenbank
  • CIAS/cias-registration – RegistrationService (provision, assignTenant, grantRoles, requireRolesExist, passwordSetupContext)
  • CIAS/cias-tenancy – TenantService (createTenant)
  • CIAS/cias-iam-keycloak – KeycloakIdentityAdapter, KeycloakOrganizationAdapter, KeycloakRoleAdapter
  • CIAS/cias-spring-boot-starter – RegistrationUserHook, RegistrationDefaultGroupHook
  • CIAS/cias-registration/docs/adr – ADR-011, ADR-029
Suchen