CodamAIDocs
Themafertig

Ein neuer Kunde wird eingerichtet

Eine Firma registriert sich selbst, wird freigegeben, bekommt ihren Mandanten und ihre erste Administratorin, die sofort Daten anlegt.

Ausprägungen
mit Freigabeohne FreigabeMULTI: eigene DatenbankSINGLE: keine eigene DatenbankAdresse schon bekanntSchlüssel schon vergebenBereitstellung scheitert

Worum es geht

Die Nordbau GmbH will die Anwendung nutzen. Niemand legt ihr von Hand etwas an: Anna Berg füllt ein öffentliches Formular aus, und am Ende gibt es einen Mandanten nordbau-gmbh, eine Organisation in Keycloak, eine Datenbank und ein Konto, das darin arbeiten kann.

Diese Seite spielt den Fall einmal von vorn bis hinten durch. Für die Einzelheiten verlinkt sie die Seiten, die den jeweiligen Schritt allein beschreiben.

Die Beteiligten

WerWas er in diesem Fall tut
Anna Bergfüllt das Formular aus, klickt den Link, setzt ihr Passwort, legt die ersten Daten an
CIASführt den Registrierungsvorgang, legt Mandant und Organisation an, vergibt die Startrollen
Keycloakhält das Konto, die Organisation und später das Token
Plattform-Administratorgibt die Registrierung frei
Persistenz (CDMS)legt die Datenbank des Mandanten an und migriert ihr Schema
CDMSliefert die Daten, sobald Anna angemeldet ist

Wer welche Farbe hat, steht unter Die Beteiligten einer Anfrage.

Der ganze Weg

sequenceDiagram
    participant B as Anna
    participant C as CIAS
    participant K as Keycloak
    participant M as E-Mail
    participant A as Plattform-Admin
    participant P as Persistenz
    B->>C: POST /cias/registration/self<br/>email, Vorname, Nachname, company „Nordbau GmbH“
    C->>C: Drosselung, Felder prüfen, Schlüssel nordbau-gmbh bilden
    C->>K: Konto deaktiviert und unbestätigt anlegen
    C->>M: Bestätigungsmail mit Einmal-Link
    C-->>B: 202 accepted
    M-->>B: Mail
    B->>C: klickt den Link (POST /cias/registration/verify)
    C->>M: „Ihre Registrierung wird geprüft“
    Note over C,A: Vorgang wartet in PENDING_APPROVAL
    A->>C: POST /cias/admin/registrations/{id}/approve
    C->>K: Adresse bestätigt, Konto freischalten, Passwort verlangen
    C->>K: Organisation nordbau-gmbh anlegen
    C->>P: Mandant anlegen, Datenbank einrichten
    P-->>C: fertig
    C->>K: Anna wird Mitglied der Organisation
    C->>K: Attribute tenant und allowedTenants setzen
    C->>K: Startrollen in der Organisation vergeben
    C->>C: Benutzerdatensatz anlegen, Vorgang COMPLETED
    C->>M: Willkommensmail, möglichst mit Link zum Passwort-Setzen

Block 1: Die Person beweist ihre Adresse

Vom Formular bis zum Klick
  1. 1
    Benutzer→CIAS
    schickt das Formular ab. Pflicht sind email und company, ein Passwortfeld gibt es nicht
  2. 2
    CIAS
    prüft die Drosselung: höchstens 10 Versuche je Adresse in 10 Minuten
  3. 3
    CIAS
    bildet aus company den Mandantenschlüssel. Aus „Nordbau GmbH“ wird nordbau-gmbh
  4. 4
    CIAS→Keycloak
    legt das Konto deaktiviert und unbestätigt an
  5. 5
    CIAS→E-Mail
    schickt die Bestätigungsmail. Gespeichert wird nur der Hash des Links
  6. 6
    CIAS→Benutzer
    antwortet 202 { "status": "accepted" } – dieselbe Antwort, egal ob die Adresse neu ist
  7. 7
    Benutzer→CIAS
    klickt den Link. Er gilt in cias-runtime 24 Stunden und nur einmal
    Ergebnis: Vorgang VERIFIED. Es gibt noch keinen Mandanten und keine Rollen

Einzelheiten: Selbstregistrierung, E-Mail bestätigen, Der Mandantenschlüssel.

Block 2: Ein Mensch gibt frei

Ein öffentliches Formular, das Mandanten anlegt, legt sie in dem Takt an, in dem es aufgerufen wird. Deshalb steht in cias-runtime die Freigabe standardmäßig auf „nötig“ (CIAS_SELF_SERVICE_APPROVAL).

Die Freigabe
  1. 1
    CIAS
    Vorgang → PENDING_APPROVAL, die Person bekommt die Mail APPROVAL_PENDING
  2. 2
    Admin→CIAS
    findet den Vorgang über GET /cias/admin/registrations?state=PENDING_APPROVAL
  3. 3
    CIAS
    prüft, dass der Aufrufer Plattform-Administrator ist
    Eine Mandanten-Administratorin darf nicht freigeben
  4. 4
    Admin→CIAS
    approve – und im selben Aufruf beginnt die Bereitstellung
    Ergebnis: APPROVED → PROVISIONING

CIAS schickt Administratoren keine Mail, wenn etwas zu genehmigen ist. Die Verwaltungsoberfläche fragt die Liste ab. Einzelheiten: Freigabe durch einen Administrator.

Block 3: Alles entsteht auf einmal

Die Bereitstellung, in dieser Reihenfolge
  1. 1
    CIAS
    bestimmt die Startrollen für die Situation TENANT_FOUNDER und prüft, dass es jede davon gibt
    fehlt eine Rolle: FAILED
  2. 2
    CIAS→Keycloak
    Adresse als bestätigt markieren, Konto freischalten, „Passwort setzen“ verlangen
  3. 3
    CIAS→Keycloak
    Organisation anlegen: Alias nordbau-gmbh, Name „Nordbau GmbH“
  4. 4
    CIAS→Datenbank
    Mandant nordbau-gmbh anlegen, Art DYNAMIC, mit Verweis auf die Organisation. In MULTI wird dabei die Datenbank des Mandanten eingerichtet
  5. 5
    CIAS→Keycloak
    Anna wird Mitglied der Organisation
  6. 6
    CIAS→Keycloak
    Attribute tenant und allowedTenants am Konto auf nordbau-gmbh setzen
  7. 7
    CIAS→Keycloak
    Startrollen vergeben, in der Organisation, auf dem Client dieser Installation
  8. 8
    Hook
    CIAS legt den Benutzerdatensatz an und setzt ihn auf ACTIVE, danach laufen eigene Hooks
  9. 9
    CIAS→E-Mail
    Willkommensmail, möglichst mit Link zum Passwort-Setzen
    Ergebnis: Vorgang COMPLETED. Anna kann sich anmelden

Scheitert einer dieser Schritte, endet der Vorgang in FAILED. Ein Plattform-Administrator wiederholt ihn dann mit retry oder verwirft ihn mit discard. Einzelheiten: Was beim Abschluss passiert.

Die beiden Zustandsreihen nebeneinander

Registrierung und Mandant haben eigene Zustände. Sie hängen zusammen, aber sie sind nicht dasselbe. Die Registrierung ist ein Vorgang, der endet; der Mandant ist ein Kunde, der bleibt.

MomentRegistrierungMandant: StellungMandant: Rollout
Formular abgeschicktPENDING_VERIFICATIONgibt es noch nicht–
Link geklicktVERIFIEDgibt es noch nicht–
wartet auf FreigabePENDING_APPROVALgibt es noch nicht–
genehmigtAPPROVED → PROVISIONINGgibt es noch nicht–
Datensatz geschriebenPROVISIONINGPENDINGIN_PROGRESS
Datenbank eingerichtetPROVISIONINGACTIVEPROVISIONED
Rollen, Benutzerdatensatz, MailCOMPLETEDACTIVEPROVISIONED

Der Mandant entsteht also erst im letzten Block und ist innerhalb weniger Augenblicke ACTIVE. Bedient wird er, sobald die Stellung ACTIVE ist und das heutige Datum im Gültigkeitsfenster liegt. Alle Zustände einzeln: Die Zustände einer Registrierung und Der Lebenslauf eines Mandanten.

Das Passwort und der erste Login

CIAS sieht nie ein Passwort. Die Willkommensmail enthält einen Link auf die Passwortseite von Keycloak; lässt sich der Link nicht erzeugen, führt die Mail zur Anmeldung, und Anna nutzt dort „Passwort vergessen“.

Vom Passwort zum Token
  1. 1
    Benutzer→Keycloak
    setzt das Passwort auf der Seite von Keycloak
  2. 2
    Benutzer→Keycloak
    meldet sich an
  3. 3
    Keycloak→Client
    stellt das Token aus: Claim organization mit nordbau-gmbh, Attribute tenant und allowedTenants, die Startrollen in der Organisation
    Ergebnis: Der BFF hält das Token und schickt es bei jeder Anfrage mit

Einzelheiten: Das Passwort setzen, Anmelden im Browser, Passwort-Setz-Link erneut schicken.

Die erste Anfrage an CDMS

Annas erste Liste
  1. CIAS
    Token prüfen
    Ist das Token gültig und nicht abgelaufen?
    ↳ nein 401
  2. CIAS
    Mandant bestimmen
    Genau eine Organisation im Token → nordbau-gmbh
    ↳ nein 403 cias.authentication.tenant-unresolved
  3. CIAS
    Mandanten-Tor
    Wird nordbau-gmbh bedient, also ACTIVE und im Gültigkeitsfenster?
    ↳ nein 403 cias.authentication.tenant-not-served
  4. CIAS
    Effektive Rollen
    Hat Anna Rollen in der Organisation? Dann gelten nur diese
  5. CDMS
    Modellrolle
    Erlaubt eine ihrer effektiven Rollen das Lesen dieses Modells?
    ↳ nein 403
  6. CDMS
    Datenbank
    In MULTI: die Datenbank von nordbau-gmbh
  7. Die Liste kommt zurück – leer, denn der Mandant ist neu

Den vollständigen Weg beschreibt Vom Login bis zu den Daten.

Was die Gründerin kann – und was die Installation dafür einrichten muss

Die Startrollen sind kein fester Code, sondern ein Regelwerk. Was die Gründerin am ersten Tag tun kann, hängt deshalb daran, was die Installation in dieses Regelwerk geschrieben hat.

Was die Gründerin tun kann
Was sie tun willWoran es hängtWas dafür nötig ist
sich anmelden und in ihrem Mandanten arbeitenMitgliedschaft in der Organisationentsteht bei der Bereitstellung, ist also da
Daten in CDMS lesen und anlegenModellrollen von CDMSDie Startrollen-Regel der Installation muss sie nennen. Die ausgelieferte Grundeinstellung vergibt nur tenant-owner, tenant-admin und tenant-user
eine Kollegin einladendie Rollen aus required-caller-roles des Ablaufs TENANT_ADMINausgeliefert ist tenant-admin, und die Gründerin bekommt sie mit ihren Startrollen
einer Kollegin eine Rolle gebenDelegation im Rollenkatalog und ObergrenzeAusgeliefert: tenant-user und tenant-admin kann sie vergeben, denn beide sind an ihre Rollen delegiert und sie hält sie selbst. tenant-owner vergibt nur ein Plattform-Administrator. Für weitere Rollen, etwa aus CDMS, muss die Installation Delegation und Startrollen einrichten
Mandanten anlegen oder sperrenPlattformrolledarf nur ein Plattform-Administrator, nie eine Mandanten-Administration

Verwalten kann die Gründerin ihren Mandanten also ab dem ersten Tag allein. Soll sie auch mit den Daten arbeiten, schreibt die Installation eine Regel der Installation für die Situation TENANT_FOUNDER mit den Modellrollen und trägt die passenden Delegationen in den Rollenkatalog ein. Beides sind bewusste Entscheidungen der Plattform, kein Nebeneffekt der Registrierung.

Einzelheiten: Startrollen als Regelwerk, Eine Rolle vergeben, Der Rollenkatalog, Die Obergrenze.

Die Ausprägungen

Wie der Fall abweichen kann

Wann: Die Installation setzt approval-required: false, wie es der Hub tut.

Block 2 entfällt. Nach dem Klick auf den Link beginnt sofort die Bereitstellung, und die Willkommensmail kommt wenige Sekunden später.

Ergebnis: Wer so arbeitet, braucht einen anderen Schutz vor massenhaft angelegten Mandanten, etwa eine Oberfläche nur mit Einladungscode.

Wann: CDMS_TENANT_MODE=MULTI und die CDMS-Persistenz läuft im selben Prozess.

Beim Anlegen des Mandanten wird die Datenbank nordbau-gmbh angelegt und ihr Schema migriert. Das dauert Sekunden bis Minuten und geschieht vor der Willkommensmail.

Ergebnis: Die erste Anfrage des Kunden trifft eine fertige Datenbank. Siehe Datenbanken, Pools, Migration.

Wann: CDMS_TENANT_MODE=SINGLE, oder CIAS läuft als eigener Dienst ohne CDMS-Persistenz.

Die Einrichtung hat nichts zu tun und meldet sofort Erfolg. Bei einem eigenständigen CIAS legt CDMS die Datenbank später bei der ersten Anfrage an.

Ergebnis: Der Mandant ist sofort ACTIVE. In SINGLE spielt er für Anfragen keine Rolle, siehe In SINGLE zählt der Mandant im Token nicht.

Wann: Zu Annas Adresse gibt es bereits ein Konto, etwa bei einem anderen Kunden.

CIAS legt kein zweites Konto an und ändert am bestehenden nichts, auch nicht das Passwort. Sie bekommt statt der Bestätigungsmail eine Mail, die zum Beitritt führt. Löst sie den Link ein, entsteht der neue Mandant, und ihr bestehendes Konto wird seine Gründerin. Die Antwort an das Formular ist dieselbe wie bei einer neuen Adresse.

Ergebnis: Siehe Die E-Mail ist das Konto.

Wann: Es gibt schon einen Mandanten nordbau-gmbh.

Schon beim Absenden des Formulars versucht CIAS nordbau-gmbh-2 bis -20. Der Anzeigename bleibt „Nordbau GmbH“.

Ergebnis: Siehe Der Mandantenschlüssel.

Wann: Keycloak ist nicht erreichbar, eine Startrolle fehlt, oder ein eigener Hook wirft.

Der Vorgang geht nach FAILED. Die Person bekommt keine Mail. Der Fehler trifft die Anfrage, die die Bereitstellung ausgelöst hat – hier also den Aufruf approve des Administrators.

Ergebnis: Ein Plattform-Administrator behebt die Ursache und ruft retry auf, oder verwirft den Vorgang mit discard.

Wann: Eine Installation stellt tenant-assignment: NONE ein.

Es entsteht kein Mandant und keine Organisation. Die Person bekommt die Rollen der Situation TENANTLESS. Das Feld company braucht es dann nicht.

Ergebnis: Sinnvoll nur dort, wo ein Mensch den Mandanten danach zuordnet.

Fallen

Weiter

Quellen im Code und in der Wissensdatenbank
  • CIAS/cias-registration – RegistrationService (register, verify, approve, provision, assignTenant, writeTenantAttributes, grantRoles), RegistrationState, RegistrationSituation, SlugTenantKeyFactory
  • CIAS/cias-registration – RegistrationController (/self, /verify), RegistrationAdminController (approve, retry, discard)
  • CIAS/cias-tenancy – TenantService (createTenant, rollOut), Tenant (TenantStatus, ProvisioningState)
  • CIAS/cias-user – RegistrationUserHook, UserService.record/activate
  • CIAS/cias-authentication – TokenParser.admit, OrganizationTenantResolver, TenantGate, EffectiveRoles
  • CIAS/cias-runtime – application.yml (flows.SELF_SERVICE, flows.TENANT_ADMIN), CiasRegistrationRoleConfiguration, CiasIdentityRegistry
  • commons-persistence – TenantProvisioningPort, DatabaseTenantProvisioningAdapter
Suchen