Authentifizierung, Mitgliedschaften, Einladungen und Abrechnung brauchen Organisationsgrenzen im Datenmodell und in der Sitzung, nicht nur in der Benutzeroberfläche.

  1. 01Anfrage
  2. 02Sitzung → aktive Organisation
  3. 03Rollenprüfung
  4. 04Mandantenbezogene Abfrage
  5. 05Antwort
Die aktive Organisation kommt aus der Sitzung, nie aus einer frei wählbaren Client-ID.

Aktive Organisation aus der Sitzung

API und UI sollten die aktive Organisation aus der Sitzung ermitteln, nicht aus einer frei wählbaren Client-ID. Diese eine Regel verhindert die meisten mandantenübergreifenden Datenlecks und vereinfacht die Autorisierung.

Grenzen doppelt durchsetzen

Jede mandanteneigene Tabelle trägt einen Organisationsschlüssel. Prüfungen in der Anwendung filtern danach, und Datenbank-Policies setzen ihn zusätzlich durch, sodass ein vergessener Filter nicht zum Datenleck wird. Tests versuchen gezielt mandantenübergreifende Zugriffe.

Mitgliedschaften und Rollen als Produktoberfläche

Einladungen, Admin-Rollen und persönliche Organisationen sind Produktfunktionen. Behandeln Sie sie mit derselben Sorgfalt wie kundenseitige Abläufe: klare Zustände, ehrliche Fehlermeldungen und Tests für die schwierigen Pfade.

Abrechnung liegt auf derselben Grenze

Abonnements hängen an Organisationen. Planen Sie das früh, auch wenn die Abrechnung erst später kommt; Mandantenfähigkeit nachträglich in die Abrechnung einzubauen kostet mehr, als eine saubere Schnittstelle vorzusehen.

Ein bestehendes Produkt migrieren

  1. Organisationsschlüssel zu mandanteneigenen Tabellen hinzufügen.
  2. Bestehende Daten pro Kunde in eine Standardorganisation übertragen.
  3. Die Schlüssel in Abfragen und Datenbank-Policies durchsetzen.
  4. Alte Codepfade entfernen, sobald die Tests auf produktionsnahen Daten bestehen.

Die Ledger-Fallstudie beschreibt, wie wir Authentifizierung, Autorisierung und Abonnements in einem Finanzprodukt gebaut haben. Zur Architekturplanung finden Sie mehr bei Product Engineering und Softwarearchitektur.