Bis hierher hatte die Kladde ein Büro, und das Büro war das Entra-Verzeichnis, aus dem seine Leute sich anmelden. In dieser Lektion bekommt die Kladde ein Verzeichnis der Büros. Ein Büro wird registriert und bekommt eine eigene Mandanten-Id. Jede Anfrage findet ihr Büro über den Token, und ein Büro lässt sich sperren und am Ende ganz entfernen. Am Schluss arbeiten zwei erfundene Büros gleichzeitig in Ihrer Kladde, Büro Nord und Büro Süd, und ein Test beweist, dass keines die Kontakte des anderen sieht.

Das Büro bekommt eine eigene Id

Seit Lektion 4.3.5 liest ClaimsCurrentUser die Verzeichnis-Id tid aus dem Token und macht daraus die TenantId. Das war für ein Büro richtig und einfach. Für mehrere Büros reicht es nicht:

  • Ein Verzeichnis ist noch kein Büro. Die Anmeldung nimmt seit 4.7.3 Tokens aus mehreren Entra-Verzeichnissen an. Wer sich anmelden kann, ist aber noch kein Kunde. Die Kladde muss wissen, welche Verzeichnisse zu einem registrierten Büro gehören.
  • Ein Büro kann mehrere Verzeichnisse haben, etwa nach dem Zusammenschluss zweier Büros. Und es kann sein Verzeichnis wechseln. Wäre tid der Schlüssel aller Daten, müsste dann jede Zeile, jedes Ereignis und jeder Grain-Zustand umziehen.
  • Ein Büro hat einen Zustand. Aktiv, gesperrt, im Entfernen: Das steht in keinem Token.

Die Kladde trennt deshalb zwei Ids. Die Verzeichnis-Id (tid) sagt, woher eine Person kommt. Die Mandanten-Id (TenantId) sagt, wem die Daten gehören, und steht in jedem Schlüssel. Dazwischen steht das Verzeichnis der Büros im Kontext Mandanten.

Bleibt eine Frage, die Sie in Lektion 4.9.1 als Risiko notiert haben: Das erste Büro hat Angebote, Ereignisse und Grain-Zustände unter seiner bisherigen TenantId, und die war sein tid. Die Lösung ist schlicht: Das erste Büro behält diese Id. Es wird mit TenantId = sein bisheriger tid registriert, und kein gespeicherter Schlüssel ändert sich. Jedes weitere Büro bekommt eine neue Id, die mit keinem Verzeichnis etwas zu tun hat. Dass die erste Id zufällig einem tid gleicht, ist danach bedeutungslos. Halten Sie die Entscheidung als ADR fest:

markdown
# 0027: Eigene Mandanten-Id statt tid

- Status: angenommen
- Zuversicht: hoch

## Kontext

Die Kladde nimmt Anmeldungen aus mehreren Entra-Verzeichnissen an (ADR 0015). Bisher ist die TenantId der tid aus dem
Token. Ein Büro kann aber mehrere Verzeichnisse haben oder sein Verzeichnis wechseln, und ein Verzeichnis ohne Vertrag
darf nichts sehen.

## Optionen

### Option 1: tid bleibt die TenantId, dazu eine Liste freigeschalteter Verzeichnisse
### Option 2: eine eigene TenantId je Büro, das Verzeichnis der Büros ordnet tid → Büro zu

## Entscheidung

Option 2. Der Kontext Mandanten ordnet jedem Verzeichnis höchstens ein Büro zu. Das erste Büro behält als TenantId
seinen bisherigen tid, damit kein gespeicherter Schlüssel umzieht.

## Abwägungen

Daten hängen nicht mehr an der Anmeldung; Verzeichnisse lassen sich zuordnen und wechseln. Dafür braucht jede Anfrage
eine Nachfrage im Verzeichnis der Büros, für 30 Sekunden zwischengespeichert.

## Folgen

Neuer Kontext Mandanten mit Steuerung (POST /ops/tenants), Middleware für die Auflösung, ClaimsCurrentUser liest das
Büro aus CurrentTenant.

## Folgen für Sicherheit und Datenschutz

Ein Verzeichnis ohne Büro bekommt 403 und sieht nichts. Eine Sperre wirkt erst nach bis zu 30 Sekunden auf jedem
Replikat; muss eine Sperre bei einem Einbruch sofort wirken, startet der Betrieb die Replikate neu.

## Überprüfen, wenn

- ein Büro Gäste aus fremden Verzeichnissen einlädt (B2B) und deren tid nicht seinem Büro gehört,
- die Nachfrage im Verzeichnis der Büros in den Antwortzeiten (p95) sichtbar wird.

Das ADR folgt der Vorlage aus Lektion 4.1.3, und der Test der ADRs aus derselben Lektion prüft seine Form. Die Nummern sind Beispiele; Ihre ADRs haben eigene.