Was hat sich geändert

Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.

Version 1 → 2

Kleine Korrektur

3 Lektionen aktualisiert

Kleine Korrekturen wie Tipp- oder Übersetzungsfehler. Lernende werden nicht benachrichtigt.

Die Trennung zwischen Kunden beginnt mit einer Frage: Zu welchem Tenant gehört diese Anfrage? ### Monopam Ab v2026.09 leitet Monopam den Tenant **nur aus Hostname und Port der Anfrage** ab. Jeder Tenant hat seine Hostnamen; eine Adresse, die keinem Tenant gehört, erreicht keinen Tenant. Ein vom Client gesendeter Tenant-Header wird nicht beachtet. Eine angemeldete Sitzung ist an den Tenant gebunden, für den sie ausgestellt wurde. An der Adresse eines anderen Tenants wird sie abgelehnt (HTTP 401) und die Person zur Abmeldung geleitet. Eine Sitzung kann nicht in mehreren Tenants handeln. ### Monosign Monosign hält alle Tenants in einer Datenbank und filtert jede tenantbezogene Tabelle nach Tenant. Der Tenant wird in dieser Reihenfolge bestimmt: ein vom API-Aufrufer genannter Tenant-Header, dann Hostname und Port, dann der aktive Standard-Tenant. Browser werden über den Host aufgelöst. ::diagram msp-tenant-resolution ### Was das für Ihren Entwurf bedeutet - Geben Sie jedem Kunden in beiden Produkten einen eigenen Hostnamen. Host und Port müssen über alle Tenants eindeutig sein. - Vor Monopam muss Ihr Proxy den ursprünglichen `Host`-Header und `X-Forwarded-Proto` durchreichen. Eine Installation antwortet für einen unbekannten Host auf jeder Seite mit 404. - Planen Sie keine gemeinsame Adresse mit Kundenauswahl. In Monopam gibt es das nicht. > Hinweis: Nach dem Upgrade auf Monopam v2026.09 meldet sich jeder Benutzer einmal neu an, weil die Cookie-Schlüssel in die Datenbank verlegt wurden.

Tenants auf App-Server verteilen

Eine Monopam-Installation bedeutet eine Installationsdatenbank, ein Redis und einen Vault-Schlüssel. Sie kann auf mehreren App-Servern laufen. Zwei Umgebungseinstellungen je Server legen dessen Anteil fest: - `MONOPAM_SERVED_TENANTS`: die Tenants, für die dieser Server antwortet. Adressen anderer Tenants erhalten die Seite "Tenant nicht gefunden". - `MONOPAM_JOB_TENANTS`: die Tenants, für die dieser Server Hintergrundjobs ausführt (Rotation, Discovery, Benutzersynchronisation, Zertifikatsjobs, Alarme). ``` # Hauptserver: antwortet für jeden Tenant, führt nur eigene Jobs aus MONOPAM_SERVED_TENANTS=* MONOPAM_JOB_TENANTS=default # Kundenserver: antwortet und führt Jobs für einen Tenant aus MONOPAM_SERVED_TENANTS=tenant-a MONOPAM_JOB_TENANTS=tenant-a ``` Ohne beide Einstellungen bedient ein einzelner Server jeden Tenant und führt jeden Job aus. ::diagram msp-app-servers ### Regeln für den Plan - **Jeder Tenant-Name steht in der Jobliste genau eines Servers.** Ein Tenant auf zwei Servern erhält Rotationen, Alarme und Synchronisationen doppelt. - Auf einer leeren Datenbank startet der Hauptserver zuerst; er legt den Standard-Tenant an. - Ein Server, der einen Tenant mit eigener Datenbank bedient, braucht Netzwerkzugriff auf diese Datenbank und auf die Installationsdatenbank. - Ein Tenant mit eigener Datenbank wird am besten von einem eigenen App-Server bedient. ### Was ein Server nicht isoliert Innerhalb einer Jobschleife stoppt ein fehlerhafter Tenant die Schleife für diese Runde; gemeinsame Tenants laufen zuerst, solche mit eigener Datenbank danach. Eine ausgefallene eigene Datenbank hält daher die Tenants der Installationsdatenbank nicht auf.

Die eigene Installation des Kunden: Remote-Tenants

Manche Kunden legen ihre privilegierten Daten nicht in die Umgebung eines Providers. Mit einem **Remote-Tenant** betreiben sie Monopam selbst und bleiben dennoch Ihr betreuter Kunde. ### So funktioniert die Verbindung 1. Sie legen den Remote-Tenant an und erhalten einen einmaligen Registrierungscode, 24 Stunden gültig und nur einmal angezeigt. 2. Der Kunde registriert seine Installation mit Ihrer Adresse und dem Code. Sie erzeugt eigene Schlüssel; die privaten Schlüssel verlassen sie nie. 3. Die Installation des Kunden hält **einen ausgehenden WebSocket** zu Ihnen. Sie verbinden sich nie zum Kunden, und der Kunde braucht keine eingehende Regel. Jede Nachricht ist signiert und nur einmal gültig. Sie können dem Kunden fertige Bereitstellungsdateien geben (Docker Compose, Kubernetes oder OpenShift). Seine Geheimnisse entstehen auf seinen eigenen Maschinen; nichts über seine Datenbank wird bei Ihnen gespeichert. ### Wer entscheidet was - Sie **schlagen vor**, welche Ihrer Mitarbeiter mit welcher Rolle eintreten dürfen. - Der Kunde **genehmigt jede Person** und wählt die Richtlinien, die bestimmen, was sie sieht. Jede Änderung von Ihnen verlangt eine erneute Genehmigung. - **Disconnect Provider** ist der Schalter des Kunden: Ihre Sitzungen enden binnen Sekunden, und niemand von Ihnen kommt hinein, bis der Kunde wieder verbindet. - **Offline tolerance** (1 Stunde, 4 Stunden, standardmäßig 24 Stunden oder 7 Tage) legt fest, wie lange Ihr Zugriff ohne neue Synchronisation weiterarbeitet. ::diagram msp-remote-tenant-link ### Was Sie nicht können - Hosts, Benutzer, Seed oder Einstellungen des Remote-Tenants verwalten oder seine Richtlinien sehen. - Gruppenzugriffe verwenden oder Richtlinien selbst wählen. - Die Webadresse des Kunden über die Verbindung erreichen. Ihre Mitarbeiter nutzen den Weg, den der Kunde ihnen gibt, etwa ein VPN. > Warnung: Ein neuer Registrierungscode trennt die verbundene Installation endgültig; sie muss sich neu registrieren.