Multi-Tenancy

Auris ist eine Multi-Tenant-Identity-und-Access-Management-Plattform. Jede Instanz bedient einen oder mehrere Tenants, von denen jeder eine isolierte Organisationseinheit mit eigenen Benutzern, Anwendungen, Rollen, Berechtigungen, Sicherheitsrichtlinien und Branding darstellt. Diese Seite erklärt, wie Tenancy auf jeder Systemschicht funktioniert.

Das Auris-Tenant-Modell

Ein Tenant in Auris repräsentiert eine einzelne Organisation, ein Unternehmen oder eine Umgebung, die Auris für Authentifizierung und Autorisierung verwendet. Jeder Tenant erhält:

• Seine eigene Gruppe von Benutzern (standardmäßig wird kein Benutzer tenantübergreifend geteilt)
• Seine eigenen Anwendungen (jede mit eigenen OAuth-Client-Anmeldedaten)
• Seine eigenen Rollen und Berechtigungen (RBAC, FGA-Modelle, benutzerdefinierte Claims)
• Seine eigenen Sicherheitsrichtlinien (MFA-Durchsetzung, Sitzungsrichtlinien, Rate-Limits, IP-Regeln, CAPTCHA)
• Sein eigenes Branding (Logo, Farben, Firmenname, benutzerdefinierte Domain)
• Sein eigenes Abrechnungsabonnement (Plan, Zahlungsmethode, Rechnungen)
• Seine eigenen Audit-Protokolle (Authentifizierungsereignisse, Admin-Aktionen, Richtlinienänderungen)

Tenants sind die Isolierungsgrenze der obersten Ebene in Auris. Zwischen Tenants leckt nichts durch.

Ein Tenant = Ein Keycloak-Realm

Im Hintergrund wird jeder Auris-Tenant auf genau einen Keycloak-Realm abgebildet. Keycloak ist der Identity Provider, den Auris mit seiner übergeordneten API umhüllt.

Auris Tenant "acme-corp"  ←→  Keycloak Realm "acme-corp"
Auris Tenant "beta-inc"   ←→  Keycloak Realm "beta-inc"
Auris Tenant "staging"    ←→  Keycloak Realm "staging"

Diese Abbildung bietet mehrere Garantien:

Vollständige Datenisolierung

Keycloak-Realms sind auf Datenbankebene vollständig isoliert. Benutzer, Clients, Rollen, Sitzungen und Anmeldedaten in einem Realm können von einem anderen Realm nicht zugegriffen werden. Dies ist keine Filterung auf Anwendungsebene — sie wird durch das Datenmodell von Keycloak durchgesetzt.

Separate Authentifizierungsinfrastruktur

Jeder Realm hat seine eigenen:

• Login-Endpunkte und Sitzungsverwaltung
• SSO-Cookies (ein in Realm A angemeldeter Benutzer ist nicht in Realm B angemeldet)
• Identity-Provider-Konfigurationen (Social-Login, SAML, OIDC-Federationen)
• Authentifizierungs-Flows und erforderliche Aktionen
• Passwortrichtlinien und Anmeldedaten-Verwaltung

Unabhängiges Schlüsselmaterial

Jeder Realm kann seine eigenen Signaturschlüssel für JWTs haben. Das bedeutet, Tokens für einen Tenant können nicht gegen den JWKS-Endpunkt eines anderen Tenants verifiziert werden, selbst wenn das Token abgefangen wurde.

Datenisolierung im Detail

Die Datenisolierung funktioniert auf mehreren Schichten:

Keycloak-Schicht

Auris Prisma-Schicht

Alle Auris-spezifischen Datenmodelle enthalten ein tenantId-Feld, das Abfragen begrenzt:

Jede serverseitige Service-Methode in Auris akzeptiert oder leitet tenantId aus dem authentifizierten Anfrage-Kontext ab und verwendet ihn, um Datenbankabfragen zu begrenzen. Es gibt keine Cross-Tenant-Abfragen im Anwendungscode.

API-Schicht

Die API erzwingt Tenant-Isolierung an der Anfrageegrenze. Jede authentifizierte Anfrage muss einen gültigen Tenant-Bezeichner enthalten (über den x-tenant-Header oder aus dem Zugriffstoken abgeleitet). Wenn der authentifizierte Benutzer nicht zum angeforderten Tenant gehört, gibt die API 403 Forbidden zurück.

Tenant-Identifikation

Anwendungen und API-Clients identifizieren, gegen welchen Tenant sie operieren, über den x-tenant-HTTP-Header.

Der x-tenant-Header

GET /api/users
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
x-tenant: acme-corp

Der x-tenant-Header-Wert ist der Slug des Tenants — ein URL-sicherer Bezeichner, der bei der Tenant-Erstellung festgelegt wird. Er wird direkt dem Keycloak-Realm-Namen zugeordnet.

Handhabung durch die SDKs

Die Auris SDKs fügen den x-tenant-Header automatisch bei jeder Anfrage ein, basierend auf der konfigurierten Domain oder Tenant-ID:

// @auris/js
const auris = new AurisClient({
  domain: 'acme-corp.auris.example.com',
  clientId: 'your-client-id',
})
// SDK extrahiert Tenant aus Domain und sendet x-tenant-Header automatisch

Konsolen-API-Client

Der interne API-Client der Auris-Konsole (api-client.ts) sendet den x-tenant-Header bei jeder Anfrage, abgeleitet aus dem Tenant-Kontext des angemeldeten Administrators:

// Vereinfacht aus apps/console/lib/api-client.ts
const headers = {
  'Content-Type': 'application/json',
  'Authorization': `Bearer ${token}`,
  'x-tenant': currentTenant,
}

Gehostetes Login und Tenant-spezifisches Branding

Wenn ein Benutzer zur gehosteten Auris-Login-Seite weitergeleitet wird, ist die Seite entsprechend der Konfiguration des Tenants gebrandmarkt. Jeder Tenant kann folgendes anpassen:

Diese Einstellungen werden in der Konsole unter Einstellungen → Branding konfiguriert.

Wie Branding aufgelöst wird

Wenn die gehostete Login-Seite lädt, löst Auris das Branding in dieser Reihenfolge auf:

1. Anwendungsebenen-Überschreibungen: Wenn die client_id in der OAuth-Autorisierungsanfrage einer Anwendung mit benutzerdefiniertem Branding zugeordnet ist, werden diese Werte verwendet.
2. Tenant-Ebenen-Einstellungen: Für alle nicht auf Anwendungsebene überschriebenen Branding-Felder werden die Standard-Branding-Einstellungen des Tenants verwendet.
3. Plattform-Standardwerte: Wenn weder Anwendung noch Tenant eine Einstellung konfiguriert hat, werden die Auris-Plattform-Standardwerte verwendet.

Das bedeutet, ein einzelner Tenant kann für verschiedene Anwendungen unterschiedlich aussehende Login-Seiten haben, während er ein konsistentes Basis-Branding teilt.

Benutzerdefinierte Domains pro Tenant

Jeder Tenant kann eine oder mehrere benutzerdefinierte Domains konfigurieren, um das Authentifizierungserlebnis zu White-labeln. Mit einer benutzerdefinierten Domain verwenden die gehostete Login-Seite, das OIDC-Discovery-Dokument, der JWKS-Endpunkt und alle E-Mail-Links die Domain des Tenants anstelle der Auris-Plattform-Domain.

Ohne benutzerdefinierte Domain:  https://auris.example.com/hosted/login?client_id=...
Mit benutzerdefinierter Domain:  https://auth.acme-corp.com/hosted/login?client_id=...

Einrichten benutzerdefinierter Domains

1. Domain in Konsole → Einstellungen → Benutzerdefinierte Domains hinzufügen
2. Einen CNAME-DNS-Eintrag konfigurieren, der auf die Auris-Plattform zeigt
3. Auris verifiziert DNS-Eigentumsrecht über ein Verifizierungstoken (CNAME- oder TXT-Eintrag)
4. SSL/TLS wird automatisch über Let’s Encrypt provisioniert
5. Die Domain als primär festlegen, um sie für alle gehosteten Seiten und E-Mail-Links zu verwenden

Pro Tenant können mehrere Domains registriert werden (z. B. auth.acme-corp.com für Produktion und auth-staging.acme-corp.com für Staging), aber nur eine ist gleichzeitig primär.

Domain-Verifizierung

Auris unterstützt zwei Verifizierungsmethoden:

CNAME wird empfohlen, da es auch das Routing übernimmt. TXT ist für Fälle verfügbar, in denen CNAME-Einträge nicht möglich sind (z. B. Apex-Domains).

Abrechnung pro Tenant

Jeder Tenant hat sein eigenes Abrechnungsabonnement, das über die Stripe-Billing-Integration verwaltet wird.

Abonnementpläne

Auris bietet gestaffelte Pläne mit unterschiedlichen Funktionssets:

Funktionsweise der Abrechnung

• Jeder Tenant hat einen TenantSubscription-Datensatz, der auf ein Stripe-Abonnement verweist
• Der TenantStripeCustomer-Datensatz ordnet den Tenant einer Stripe-Kunden-ID zu
• Planänderungen (Upgrade/Downgrade) werden über Stripe-Checkout-Sitzungen abgewickelt
• Kündigungen werden am Ende des aktuellen Abrechnungszeitraums wirksam (cancelAtPeriodEnd)
• Stripe-Webhooks aktualisieren den Abonnementstatus in Echtzeit

Funktions-Gating

Funktionen werden basierend auf dem aktiven Plan des Tenants gesperrt. Das Modul feature-gate.ts bietet:

// Serverseitige Funktionsprüfung
const allowed = await isFeatureAllowed(tenantId, 'fga')
if (!allowed) {
  return Response.json(
    { ok: false, error: { code: 'PLAN_LIMIT', message: 'FGA requires Enterprise plan' } },
    { status: 403 }
  )
}

Feature-Gate-Prüfungen verwenden einen In-Memory-Cache mit 5-Minuten-TTL, um nicht bei jeder Anfrage die Datenbank abzufragen.

Sicherheitseinstellungen pro Tenant

Jede Sicherheitsfunktion in Auris ist auf Tenant-Ebene begrenzt. Verschiedene Tenants können völlig unterschiedliche Sicherheitshaltungen haben:

Pro-Tenant-Sicherheitskontrollen

Tenant-weit vs. Anwendungsebene

Einige Einstellungen können auf einzelne Anwendungen innerhalb eines Tenants weiter begrenzt werden:

Erstellen und Verwalten von Tenants

Erstellen eines Tenants

Die Tenant-Erstellung provisioniert den vollständigen Infrastruktur-Stack:

1. Ein neuer Keycloak-Realm wird mit dem Slug des Tenants als Realm-Name erstellt
2. Standard-Realm-Einstellungen werden angewendet (Passwortrichtlinie, Sitzungs-Timeouts, erforderliche Aktionen)
3. Die Auris-Datenbankdatensätze werden erstellt (Tenant-Konfiguration, Standardrollen, Sicherheitsstandards)
4. Ein Standard-Admin-Benutzer wird erstellt (oder eine Einladung wird gesendet)
5. Standard-Berechtigungsdefinitionen werden geseedet

Verwalten von Tenants in der Konsole

Die Tenant-Verwaltung ist unter Konsole → Einstellungen → Tenant verfügbar:

Standard-Tenant vs. Multi-Tenant-Deployments

Auris unterstützt zwei Deployment-Modi:

Einzelner Tenant (Standard)

Für viele Deployments ist ein einzelner Tenant ausreichend. Das Dashboard und die Website verwenden Auris mit einem einzigen 'altovar'-Tenant. In diesem Modus:

• Alle Benutzer gehören zum selben Tenant
• Der x-tenant-Header ist immer derselbe Wert
• Eine Tenant-Auswahl-UI ist unnötig
• Das Deployment ist einfacher zu betreiben und zu verstehen

Multi-Tenant

Multi-Tenant-Deployments bedienen mehrere Organisationen von einer einzigen Auris-Instanz. In diesem Modus:

• Jede Organisation erhält ihren eigenen Tenant mit isolierten Daten
• Die gehostete Login-Seite verwendet den Tenant-Kontext aus der client_id, um Branding aufzulösen
• Admin-Konsolen-Benutzer können nur ihren eigenen Tenant verwalten
• Die Plattform-Administration (Erstellen neuer Tenants, tenantübergreifende Ansicht) erfordert Plattform-Admin-Zugriff
• Abrechnung, Sicherheit und Branding sind pro Tenant vollständig unabhängig

Die richtige Wahl

Tenant-Daten in JWTs

Das von Auris ausgestellte Zugriffstoken enthält standardmäßig keinen tenantId-Claim. Stattdessen kodiert der iss-(Issuer-)Claim den Tenant-Kontext:

{
  "iss": "https://auth.acme-corp.com",
  "sub": "usr_abc123",
  "aud": "your-client-id"
}

Wenn du die Tenant-ID explizit im Token benötigst (für Multi-Tenant-Ressourcenserver), füge sie als Benutzerdefinierter Claim hinzu oder verwende eine Aktion, um sie einzufügen:

// Post-Login-Action: Tenant zu Token-Claims hinzufügen
return {
  allow: true,
  claims: {
    tenant_id: context.tenant.id,
    tenant_name: context.tenant.name,
  },
}

Verwandte Konzepte

• OAuth 2.0 & OIDC — Die Protokollschicht, innerhalb der Tenant-spezifische Tokens operieren
• Branding & Anpassung — Tenant-spezifisches Branding konfigurieren
• Benutzerdefinierte Domains — White-Label-Authentifizierung unter deiner Domain
• Abrechnung & Pläne — Tenant-Abonnements verwalten
• Organisationen (B2B) — Multi-Org innerhalb eines einzelnen Tenants
• Enterprise SSO — Pro-Organisations-SAML/OIDC-Federationen