Blog
Produkt-Neuigkeiten

Das Simmetric Chat Enterprise-Plugin wird vorgestellt

SSO mit SAML 2.0 und OIDC, SCIM-Provisionierung, unveränderbares Audit-Log, White-Labeling, verschlüsselte Backups und Air-Gap-Lizenzierung für regulierte Teams.

Simmetric Team9 Min. Lesezeit22/09/2026

Enterprise ist ein Plugin, kein Fork

Der üblichste Weg, wie Open-Source-Projekte eine Enterprise-Stufe ausliefern, ist ein Fork: ein privater Zweig, der von der Community-Codebasis abdriftet, bis das Upgrade zum Migrationsprojekt wird. Simmetric Chat hat den anderen Weg gewählt. Die Enterprise-Stufe wird als optionales Plugin-Paket ausgeliefert - @simmetric-chat/enterprise - das der Community-Server beim Boot über einen Plugin-Loader lädt. Der Community-Server prüft das Paket beim Start:

  • Gefunden und gültig → das Plugin registriert seine Routen, und Enterprise-Funktionen gehen live.
  • Nicht installiert → eine Info-Level-Logzeile vermerkt den Community-Build, und der Server läuft unverändert weiter.
  • Gefunden, aber defekt → der Server beendet sich laut. Eine defekte Enterprise-Installation degradiert nie still zur Community - ein halb funktionierender SSO-Stack ist schlimmer als keiner.

Dieselbe Lizenz regiert die Stufe. Die Community-Codebasis ist AGPL-3.0; das Enterprise-Plugin ist ein separat lizenziertes kommerzielles Paket, und ein Lizenz-JWT (LICENSE_KEY) entsperrt die Funktionen. Ohne gültige Lizenz mounten die Enterprise-Routen trotzdem, aber jede gegatete Funktion antwortet mit 402 und einem expliziten JSON-Payload, das die Funktion und die Stufe nennt - Ihr Integrationscode kann auf den Lizenzzustand verzweigen, statt zu raten.

Identität: SSO und SCIM out of the box

Single Sign-on unterstützt die beiden Protokolle, die Unternehmen tatsächlich betreiben: SAML 2.0 (mit Login-, Callback- und Metadaten-Endpunkten für IdP-initiierte Flows) und OIDC (Login und Callback für den Browser-Redirect-Flow, aufgebaut auf einer aktuellen OpenID-Connect-Client-Bibliothek). Beide binden an dasselbe admin-konfigurierbare SSO-Panel.

Die Konfiguration ist dort flexibel, wo es zählt. OIDC kann vollständig über das Admin-SSO-Panel konfiguriert werden (im Ruhezustand verschlüsselt in der Datenbank gespeichert), vollständig über Umgebungsvariablen oder über beides - env hat Vorrang, wenn gesetzt, sodass Infrastructure-as-Code-Bereitstellungen Provider-Einstellungen pinnen können, während das Panel sonst die Quelle der Wahrheit bleibt. Integrierte Provider decken Google, GitHub und Microsoft Entra ab, und ein generischer Provider akzeptiert jedes Discovery-Dokument.

SCIM 2.0 schließt die Lebenszyklus-Schleife: Benutzer- und Gruppen-Provisionierung über das Standard-SCIM-Protokoll mit einem Bearer-Token-geschützten Endpunkt. Wenn HR einen Benutzer in Ihrem Identity Provider ausbucht, deaktiviert sich sein Simmetric Chat-Konto über denselben Fluss - keine verwaisten Konten, kein Tabellen-getriebenes Deprovisioning. Zusammen bedeuten SSO und SCIM, dass Ihr IdP die einzige Autorität darüber bleibt, wer existiert und wer sich anmelden kann.

Das Audit-Log, das nicht umgeschrieben werden kann

Audit-Logs haben eine unbequeme Eigenschaft: Je wertvoller sie sind, desto wertvoller ist es, sie zu verändern. Das Enterprise-Audit-Log von Simmetric Chat erzwingt Unveränderbarkeit auf Datenbankebene, nicht auf Anwendungsebene.

Eine dedizierte Postgres-Rolle - simmetric_audit_writer - hält nur ein INSERT-Privileg auf der Audit-Tabelle. Das Enterprise-Plugin schreibt Audit-Ereignisse über einen separaten Verbindungspool, der sich als diese Rolle authentifiziert, sodass UPDATE und DELETE auf Datenbankebene scheitern, nicht per Anwendungskonvention. Leser gehen einen bewusst getrennten Weg über die Standard-Anwendungsverbindung, die SELECT hat, aber eine völlig andere Rolle ist - der Schreiber kann nicht lesen, und der Leser kann nicht schreiben.

Die Garantie ist ehrlich über ihre eigene Konfiguration: Wenn das Schreiber-Passwort gesetzt ist, bestätigt das Boot-Log, dass die Unveränderbarkeitsgarantie aktiv ist; wenn es fehlt, zeichnet das Audit-Log weiterhin Ereignisse auf, aber eine Boot-Warnung stellt fest, dass Datenbankebenen-Unveränderbarkeit nicht durchgesetzt wird. Fail-safe-Defaults plus ein wahrheitsgemäßes Boot-Log - das Muster, das diese Plattform überall verwendet.

Das Audit-Log wird Admins über einen Ereignisprotokoll-Viewer bereitgestellt, gegatet durch ein audit_log_immutable-Lizenzflag. Authentifizierungsereignisse, Dokumentoperationen, Einstellungsänderungen, DLP-Umgehungen, Aufbewahrungsänderungen - die Spur ist die Antwort auf „was ist tatsächlich passiert?", und sie komponiert mit der Community-RBAC-Geschichte: Der Zugriff auf das Log selbst ist eine Berechtigung.

White-Label und verschlüsselte Backups

Zwei Funktionen zielen auf Teams, die Simmetric Chat an eigene Kunden liefern oder es als interne Infrastruktur mit strengen Datenrichtlinien betreiben:

White-Labeling entfernt Produkt-Chrome von kundenorientierten Oberflächen - das eingebettete Widget, Branding-Defaults, UI-Ebene-Anpassung - unter einem dedizierten Lizenzflag. Eine Beratung, die einen Wissensassistenten für einen Kunden bereitstellt, kann den Assistenten als den eigenen des Kunden präsentieren; die Plattform bleibt im Hintergrund.

Backups gehen über Datenbank-Dumps hinaus: Geplante und On-Demand-Jobs erzeugen verschlüsselte Backup-Archive, Aufbewahrungsrichtlinien entscheiden, was wie lange aufbewahrt wird, und eine Berechtigungstrennung trennt, wer ein Ziel konfigurieren, wer einen Job ausführen, wer Logs einsehen und wer wiederherstellen darf. Die letzte Unterscheidung zählt - ein Backup auszulösen und Produktionsdaten in einen beliebigen Workspace wiederherzustellen sind unterschiedliche Vertrauensstufen, und das Berechtigungsmodell behandelt sie so.

Air-Gap-Lizenzierung für regulierte Umgebungen

Die Umgebungen, die SSO, unveränderbares Audit und kontrollierte Backups brauchen, sind häufig dieselben Umgebungen ohne Internetzugang. Enterprise-Lizenzierung ist dafür gebaut: Die Lizenz ist ein RS256-signiertes JWT, dessen eingebetteter öffentlicher Schlüssel mit dem Community-Server ausgeliefert wird. Die Verifikation passiert lokal - der Server prüft die Signatur gegen den eingebetteten Schlüssel, sodass kein Lizenzserver erreichbar sein muss. Setzen Sie LICENSE_KEY in der Server-Umgebung, starten Sie neu, und die Funktionen entsperren; entfernen Sie ihn, und sie schließen zurück zur Community mit expliziten 402-Antworten.

Dieses Design bedeutet, dass eine Enterprise-Bereitstellung vollständig in einem Rechenzentrum läuft: lokale LLMs über Ollama, lokale Vektorspeicher, lokale Embeddings, lokale OCR und jetzt lokale Lizenzvalidierung. Air-Gap ist kein später aufgesetzter degradierter Modus - es ist die Bereitstellungsform, um die dieses Produkt herum entworfen wurde.

Was das für die v0.22-Linie bedeutet

Die Community- und Enterprise-Linien bewegen sich zusammen. Der Community-Server deklariert das Enterprise-Plugin als optionale Peer-Dependency; der Loader löst es beim Boot auf, und der geteilte Plugin-Kontext injiziert die Kernanliegen (Auth, Crypto, Datenbank, Logger), sodass das Plugin nur vom geteilten Vertrag abhängen kann, nie von Community-Interna. Community-Releases und Enterprise-Releases werden gegen dieselbe geteilte Version gebaut, und ein Versionsmismatch scheitert laut beim Boot, statt zur Laufzeit fehlzuverhalten.

Für Betreiber die praktische Zusammenfassung: Installieren Sie das Plugin-Paket, setzen Sie einen gültigen LICENSE_KEY, konfigurieren Sie SSO im Admin-Panel, setzen Sie das Audit-Writer-Passwort und starten Sie neu. Das Boot-Log sagt Ihnen genau, welche dieser Schritte erfolgreich waren. Die Community-Stufe bleibt AGPL-3.0 und voll funktionsfähig - SSO, Audit und Backups sind additiv darüber, gegatet durch Lizenz statt durch einen Code-Fork.

Lesen Sie den vollständigen Leitfaden in der Doku →

Ähnliche Artikel