Zum Hauptinhalt springen

Mandanten und SpeamID/Keycloak

Zweck​

SpeamCore ist mandantenfaehig — jede Errichter-Firma laeuft in einem eigenen Datenraum mit eigenen Stammdaten, Belegen und Konfigurationen, isoliert von anderen Mandanten. Diese Trennung wird auf drei Ebenen erzwungen:

  1. Subdomain — <mandant>.speamcore.com.
  2. Keycloak-Realm — pro Mandant ein Realm mit eigenem User-Pool, eigenen Rollen und eigenem Client.
  3. CASL-Scope im Backend — clientScope filtert in vielen Models alle Datensaetze auf den aktiven Mandanten.

Aufbau​

Subdomain                Keycloak-Realm           CASL/DB-Scope
─────────                ──────────────           ─────────────
kft.speamcore.com   →    realm 'kft'        →    Mandant 'kft'
speam.speamcore.com →    realm 'speam'      →    Mandant 'speam'
demo.speamcore.com  →    realm 'demo.speamcore.com' → Mandant 'demo'

Login-Flow​

  1. Anwender ruft <mandant>.speamcore.com auf.
  2. FE leitet zum passenden Keycloak-Realm (https://account.speamid.com/realms/<realm>/...).
  3. Keycloak prueft Credentials (E-Mail + Passwort, ggf. 2FA).
  4. JWT-Token wird zurückgegeben mit Rollen-Claim (APP_SPEAMCORE_*).
  5. FE und BE bauen daraus eine CASL-Ability.
  6. BE greift bei jeder Anfrage zusaetzlich clientScope ab — alle Datenmodelle, die Mandanten-spezifisch sind, werden auf den aktiven Mandanten gefiltert.

Details siehe Berechtigungen verstehen (CASL).

SpeamID = Identitaet, Mandant = Mitgliedschaft​

Ein SpeamID-Account (eine E-Mail-Adresse) kann theoretisch mehreren Mandanten angehoeren — etwa wenn ein Berater für mehrere Errichter taetig ist. Jeder Mandanten-Wechsel ist ein neuer Login auf der jeweiligen Subdomain. Es gibt kein „Mandant wechseln"-Menue innerhalb einer SpeamCore-Session — die Trennung ist absichtlich strikt.

clientScope — was wird automatisch gefiltert?​

In den FE+BE-Codebasen wird clientScope u. a. auf folgenden Modellen angewandt:

  • Customer, Location, Supplier, Product, Workorder, SalesDocument, PurchaseDocument, ... (Stammdaten und Belege)
  • BankAccount, TransactionAccount (Buchhaltung)
  • Warehouse, WarehouseProduct, Inventory (Bestand)

Master-Stammdaten (z. B. Mengeneinheiten, HS-Codes, Hersteller-Kataloge) werden über den Setup-Wizard von einer zentralen Master-Quelle synchronisiert (siehe Setup-Wizard Schritt 7 — Master-Sync) und sind nicht Mandanten-getrennt.

Auswirkungen auf die Doku​

In jeder Routen-Funktionsseite gilt implizit: alle Daten sind mandantengescopt. Der Anwender sieht nur Datensaetze seines eigenen Mandanten. Dies muss nicht in jeder Doku-Seite wiederholt werden, ist aber Voraussetzung für alle Listen- und Detail-Endpoints.

Drift-Risiken​

  1. Lecks ohne clientScope — Wenn ein Modell ohne clientScope ausgeliefert wird, fliegt sein Inhalt mandantenuebergreifend. Code-Reviewer prüfen das.
  2. Master-Daten — Wer Master-Daten editieren kann, beeinflusst alle Mandanten. Code-Lookup: Aktuell gibt es keine dedizierte CASL-Permission do:ManageMaster — Master-Daten (z. B. Einheiten-Stamm, HsCode-Stamm) werden über Sync-Jobs vom Speam-Master gepflegt, nicht direkt im Mandanten editiert. Ausnahme: das relevant-Flag pro Einheit (siehe /units). Wenn eine zentrale Master-Daten-Verwaltung gewünscht ist, muss Marc den Subject-Namen festlegen und das BE-Modell ergaenzen.
  3. SSO-Wechsel zwischen Realms — beim Mandanten-Wechsel passiert ein vollstaendiger Logout/Login (kein Single-Click-Switch).

Verknuepfungen​

Versionshinweise​

  • 2026-04-29: Initiale Veroeffentlichung.