Eine Kollegin wird eingeladen

Worum es geht

Anna verwaltet den Mandanten nordbau. Sie will Bea dazuholen. Dafür gibt es in CIAS keinen eigenen Mechanismus: Eine Einladung ist eine ganz gewöhnliche Registrierung, nur mit der Variante TENANT_ADMIN – die Administratorin stößt sie an, und die eingeladene Person schließt sie ab.

Wer einladen darf

Bedingung	Woher sie kommt
Die Variante `TENANT_ADMIN` ist eingeschaltet	Konfiguration der Installation
Der Aufrufer hat alle Rollen aus `required-caller-roles`	Konfiguration; in `cias-runtime` ist das `tenant-admin`
Der Aufrufer hat einen Mandanten im Token	das Token selbst

Der Mandant der Einladung ist der Mandant des Aufrufers. Ein tenantKey im Payload wird verworfen, ohne geprüft zu werden. So kann niemand in einen fremden Mandanten einladen.

Der Ablauf

sequenceDiagram
    participant A as Anna (tenant-admin, nordbau)
    participant C as CIAS
    participant K as Keycloak
    participant M as E-Mail
    participant B as Bea
    A->>C: POST /cias/tenant/registrations<br/>email, firstName, lastName
    C->>C: Rolle prüfen, Mandant aus dem Token: nordbau
    C->>C: Gibt es zu der Adresse schon ein Konto?
    C->>K: nur wenn nein: Konto deaktiviert anlegen
    C->>M: Mail mit Einmal-Link auf /registration/verify
    C-->>A: 202 accepted
    M-->>B: Mail
    B->>C: öffnet den Link, löst ihn ein
    C->>K: Mitgliedschaft in nordbau, Attribute, Mitgliedsrollen
    C->>C: Benutzerdatensatz, Vorgang COMPLETED
    C->>M: Willkommensmail
    B->>K: meldet sich an

Anna erfährt aus der Antwort nicht, ob Bea schon ein Konto hat: Beide Fälle antworten 202 accepted. Nur die Mail unterscheidet sich, und die sieht nur Bea.

Die beiden Ausprägungen

Bea ist neu – oder Bea hat schon ein Konto

Kollegin neuKollegin hat schon ein Konto bei einem anderen Kunden

Wann: Zu Beas Adresse gibt es kein Konto, höchstens das Überbleibsel eines abgebrochenen Versuchs (in Keycloak deaktiviert und Adresse nie bestätigt).

1

CIAS→Keycloak
legt das Konto deaktiviert und unbestätigt an
2

CIAS→E-Mail
schickt die Mail „Adresse bestätigen“ mit dem Einmal-Link
3

Benutzer→CIAS
löst den Link ein
4

CIAS→Keycloak
Adresse bestätigt, Konto freischalten, „Passwort setzen“ verlangen
5

CIAS→Keycloak
Mitglied in nordbau, Attribute tenant und allowedTenants, Mitgliedsrollen

Ergebnis: Bea setzt ihr Passwort bei Keycloak und meldet sich an. Vorgangsart NEW_ACCOUNT.

Wann: Beas Adresse gehört schon zu einem Konto, etwa weil sie für suedlogistik arbeitet.

1

CIAS
legt kein zweites Konto an und ändert am bestehenden nichts, auch nicht das Passwort
2

CIAS→E-Mail
schickt die Mail „Einladung in einen weiteren Mandanten“ mit dem Einmal-Link
3

Benutzer→CIAS
löst den Link ein
4

CIAS→Keycloak
Mitglied in nordbau, zusätzlich zu ihren bisherigen Mitgliedschaften. Attribute tenant und allowedTenants werden auf nordbau gesetzt
5

CIAS→Keycloak
Mitgliedsrollen, in der Organisation nordbau

Ergebnis: Bea meldet sich wie gewohnt an, mit ihrem alten Passwort, und arbeitet jetzt in zwei Mandanten. Vorgangsart ADDITIONAL_MEMBERSHIP. Siehe Eine Person in zwei Mandanten.

Was sich unterscheidet

	Kollegin neu	Kollegin hat schon ein Konto
Art des Vorgangs	`NEW_ACCOUNT`	`ADDITIONAL_MEMBERSHIP`
Konto in Keycloak	wird deaktiviert angelegt und nach dem Klick freigeschaltet	bleibt unberührt
Mail	„Adresse bestätigen“	„Einladung in einen weiteren Mandanten“
Passwort	muss gesetzt werden, CIAS sieht es nie	bleibt, wie es ist; es kommt kein Passwort-Link
Nach dem Einlösen	Mitglied in `nordbau`	Mitglied in `nordbau` und in ihren bisherigen Mandanten
Benutzerdatensatz in CIAS	entsteht neu, mit `nordbau` als Heimatmandant	bleibt bestehen, der Heimatmandant ändert sich nicht

Was Bea aus der Mail heraus tut

Der Link in der Mail zeigt in beiden Ausprägungen auf dieselbe Seite: /registration/verify?token=…. Diese Seite kann zweierlei:

Vom Link zur Mitgliedschaft

1

Benutzer→Frontend
öffnet den Link aus der Mail
2

Frontend→CIAS
GET /cias/registration/invitations/{token}/form zeigt, welche Felder Anna offen gelassen hat
3

Frontend→CIAS
POST /cias/registration/verify mit dem Token – der Endpunkt /invitations/accept tut genau dasselbe
4

CIAS
Gibt es das Token, und ist es nicht abgelaufen?

nein: 404 cias.registration.not-found
5

CIAS
Vorgang → VERIFIED, dann sofort die Bereitstellung. Der Ablauf TENANT_ADMIN verlangt keine Freigabe

Ergebnis: 202 accepted, danach die Willkommensmail

Das Einlösen nimmt nur das Token entgegen. Angaben, die Anna nicht gemacht hat, bleiben leer; der Anzeigename im Benutzerdatensatz entsteht aus Vor- und Nachname und fällt sonst auf die Adresse zurück.

Wie lange der Link gilt, legt die Konfiguration des Ablaufs fest (token-ttl). In cias-runtime sind es 14 Tage.

Was Bea danach sehen darf

Beim Einlösen bekommt Bea die Rollen der Situation TENANT_MEMBER – nicht die der Gründerin. Eine Einladung darf keine Mandanten-Administration verteilen.

Stufe	Was gilt
Startrollen	die Regel des Mandanten `nordbau`, sonst die Regel der Installation, sonst die Grundeinstellung. Ausgeliefert: `tenant-user`
Wo die Rollen hängen	`nordbau` ist ein dynamischer Mandant, also in der Organisation. Bei einem statischen Mandanten werden sie global vergeben
Effektive Rollen	hat Bea in `nordbau` Rollen, ersetzen sie ihre globalen Client-Rollen. Realm-Rollen gelten immer
Daten in CDMS	Modellrollen entscheiden, welche Modelle sie überhaupt sieht; Attributfilter und Owner-Filter schneiden die Zeilen zu

Beas erste Anfrage

CIAS

Mandant bestimmen

Ist Bea in mehreren Organisationen? Dann muss der Client eine auswählen

↳ nein 403 cias.authentication.tenant-unresolved
CIAS

Mandanten-Tor

Wird nordbau bedient?

↳ nein 403 cias.authentication.tenant-not-served
CIAS

Effektive Rollen

Rollen in nordbau ersetzen die globalen
CDMS

Modellrolle

Erlaubt eine ihrer effektiven Rollen dieses Modell?

↳ nein 403
CDMS

Zeilenfilter

Attributfilter, Owner-Filter, Mandantentrennung
Bea sieht die Daten von nordbau, so weit ihre Rollen reichen

Mehr dazu: Effektive Rollen, Startrollen als Regelwerk, Die drei Ebenen im Überblick.

Will Anna Bea mehr geben als die Startrollen, vergibt sie eine Rolle über POST /cias/admin/role-assignments. Das geht nur, wenn die Rolle eine Mandantenrolle ist, an eine Rolle von Anna delegiert ist, im eigenen Mandanten vergeben wird und Anna sie selbst hält. Siehe Eine Rolle vergeben.

Wann die Einladung nicht klappt

Ablehnungen

Rollen aus `required-caller-roles`	Mandant im Token des Aufrufers	Token der Einladung	Was passiert
fehlen	–	–	403 `cias.registration.not-authorized`
vorhanden	fehlt	–	403 `cias.registration.not-authorized` – ohne Mandant ist unklar, wohin eingeladen wird
vorhanden	vorhanden	unbekannt oder abgelaufen	404 `cias.registration.not-found` – beide Fälle sehen gleich aus
vorhanden	vorhanden	schon eingelöst	202, wie beim ersten Mal. Ein zweiter Klick darf nicht zum Fehler führen
vorhanden	vorhanden	gültig	Bea wird Mitglied