Mandanten sperren, schließen, Gültigkeit

Worum es geht

Ein Kunde zahlt nicht, ein Sicherheitsvorfall wird untersucht, ein Vertrag endet: Dann soll ein Mandant nicht mehr arbeiten. CIAS bietet dafür fünf Handgriffe:

sperren: vorübergehend außer Betrieb, alles bleibt erhalten
entsperren: nach einer Sperre wieder in Betrieb
aktivieren: einen Mandanten in Betrieb nehmen, der es noch nie war
schließen: endgültig beendet, gelöscht wird nichts
Gültigkeitsfenster: ab wann und bis wann der Mandant bedient wird

Alle fünf ändern nur den Datensatz in CIAS. Keycloak und die Datenbank des Mandanten bleiben unberührt. Wirksam wird die Änderung am Mandanten-Tor, das bei jeder Anfrage fragt, ob der Mandant bedient wird.

Die Endpunkte

Alle liegen unter /cias/admin/tenants/{id}, alle verlangen einen Plattform-Administrator und antworten mit dem geänderten Mandanten.

Handgriff	Aufruf	Erlaubt aus	Event
sperren	`POST …/{id}/suspend`	jeder Stellung außer `CLOSED`	`Suspended`
entsperren	`POST …/{id}/resume`	nur `SUSPENDED`	`Resumed`
aktivieren	`POST …/{id}/activate`	`PENDING` oder `ACTIVE`, und nur wenn der Rollout `PROVISIONED` ist	`Activated`
schließen	`POST …/{id}/close`	jeder Stellung	`Closed`
Gültigkeit setzen	`POST …/{id}/validity`	jeder Stellung	–

Die {id} ist die technische ID des Mandanten, nicht sein Schlüssel. Die ID zu einem Schlüssel liefert GET /cias/admin/tenants/by-key?key=nordbau.

Die Handgriffe im Einzelnen

Was jeder Handgriff bewirkt

sperrenentsperrenaktivierenschließenkein Löschen

Wann: offene Rechnung, Sicherheitsvorfall, Wunsch des Kunden

1

Admin→CIAS
POST /cias/admin/tenants/0f6c…/suspend
2

CIAS
Stellung → SUSPENDED, Event Suspended
3

CIAS
Tor antwortet ab jetzt „nicht bedient“, nach spätestens 30 Sekunden überall

Ergebnis: Jede Anfrage für nordbau endet mit 403 cias.authentication.tenant-not-served. Die Daten bleiben, nichts muss neu eingerichtet werden.

Wann: Die Sperre ist erledigt.

1

Admin→CIAS
POST /cias/admin/tenants/0f6c…/resume
2

CIAS
Rollout PROVISIONED? ja → Stellung ACTIVE. nein → Stellung PENDING. Event Resumed

Ergebnis: Ist der Mandant gar nicht gesperrt, lehnt CIAS ab: 409 cias.tenancy.illegal-transition.resume. Ein Mandant, der vor dem Ende seiner Einrichtung gesperrt wurde, kommt als PENDING zurück und wird aktiv, sobald die Einrichtung gelingt.

Wann: Ein Mandant in PENDING soll in Betrieb, etwa nach einer Einrichtung von Hand.

1

Admin→CIAS
POST /cias/admin/tenants/0f6c…/activate
2

CIAS
Rollout PROVISIONED? ja → Stellung ACTIVE, Event Activated

Ergebnis: Ist der Rollout nicht fertig, lehnt CIAS ab: 409 cias.tenancy.illegal-transition.activate. Einen Mandanten ohne Datenbank in Betrieb zu nehmen, würde erst bei der ersten Anfrage des Kunden auffallen. Einen gesperrten Mandanten aktiviert CIAS nicht, ebenfalls mit 409: Eine Sperre hebt nur das Entsperren auf.

Wann: Der Kunde ist gegangen.

1

Admin→CIAS
POST /cias/admin/tenants/0f6c…/close
2

CIAS
Stellung → CLOSED, Event Closed

Ergebnis: Endgültig. Danach lehnen aktivieren, entsperren und sperren ab: 409 cias.tenancy.illegal-transition.activate, …resume bzw. …suspend. Schließen eines schon geschlossenen Mandanten ändert nichts.

Wann: Jemand möchte einen Mandanten „wegmachen“.

Es gibt keinen DELETE-Endpunkt. Eine Datenbank ist das eine, dessen Verlust sich nicht rückgängig machen lässt, und ein HTTP-Aufruf, der sie löscht, wäre ein größeres Risiko als eine verwaiste Datenbank. Der Datensatz bleibt auch, damit das Audit weiß, zu welchem Kunden alte Einträge gehören.

Ergebnis: Ein geschlossener Mandant belegt seinen Schlüssel weiter. Derselbe Schlüssel kann nicht für einen neuen Kunden vergeben werden.

Das Gültigkeitsfenster

Ein Mandant kann ein Fenster haben: gültig ab (validFrom) und gültig bis (validUntil). Beide sind Tage, beide zählen mit, beide dürfen leer sein. Leer heißt: nach dieser Seite offen.

Damit lässt sich ein Vertrag abbilden, ohne dass jemand am Stichtag daran denken muss:

gantt
    dateFormat YYYY-MM-DD
    axisFormat %d.%m.
    section nordbau
    angelegt und ACTIVE, aber noch nicht gültig :crit, 2026-09-22, 2026-10-01
    wird bedient                               :active, 2026-10-01, 2026-12-31
    abgelaufen, wird nicht mehr bedient        :crit, 2026-12-31, 2027-01-15

In diesem Beispiel ist validFrom = 2026-10-01 und validUntil = 2026-12-31. Der Mandant ist die ganze Zeit ACTIVE, bedient wird er aber nur vom 1.10. bis einschließlich 31.12.

Anfrage

POST /cias/admin/tenants/0f6c…/validity
{ "validFrom": "2026-10-01", "validUntil": "2026-12-31" }

Antwort

HTTP 200
{ "key": "nordbau", "status": "ACTIVE",
  "validFrom": "2026-10-01", "validUntil": "2026-12-31", … }

Was der Aufruf /validity bewirkt

validFrom im Aufruf	validUntil im Aufruf	Neues Fenster
2026-10-01	2026-12-31	1.10. bis 31.12.
leer	2026-12-31	offen bis 31.12.
leer	leer	kein Fenster mehr, jeden Tag gültig
2026-12-31	2026-10-01	400 `cias.tenancy.invalid-request`: Ende vor Beginn

Der Aufruf ersetzt immer das ganze Fenster. Ein leerer Wert heißt „offen“, nicht „wie bisher“. Wer nur das Ende verlängern will, schickt den Beginn also noch einmal mit. Und {} entfernt beide Grenzen. Genau so lässt sich ein abgelaufener Mandant wieder freischalten.

Sperren oder Fenster?

Welcher Handgriff passt?

Anlass	Ende bekannt?	Handgriff
Vertrag mit festem Beginn oder Ende	ja	Gültigkeitsfenster, es greift am Stichtag von selbst
offene Rechnung, Vorfall, Klärung	nein	sperren, später entsperren
Kunde ist endgültig weg	–	schließen

Fallen

Weiter

Der Lebenslauf eines Mandanten
Den Mandanten zulassen (Mandanten-Tor)
Ein Beispiel über beide Module: Ein Kunde kündigt