Was hat sich geändert

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

Version 10 → 11

Aktualisierung

Zwei neue Lektionen: die Installation mit dem Kunden planen (Befehle des Installers, Installationscode oder Offline-Paket, PoC oder Produktion, was der Kunde vorbereitet) sowie Gruppen, Anmelderichtlinien und externe Identity Provider. Der Wissenscheck hat drei neue Fragen. Die neuen Lektionen erhielten Diagramme.

2 Lektionen aktualisiertDauer

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

Dauer von 23 auf 24 Minuten geändert.

Die Installation mit dem Kunden planen

Ein Installationstag verläuft gut, wenn die Fragen eine Woche vorher gestellt wurden. Diese Lektion ist die Checkliste, die ein Partner mit dem Kunden durchgeht, bevor jemand den Server anfasst. ### Was der Installer ist `monofor` ist eine einzelne Linux-Binärdatei. Sie bereitet den Server des Kunden vor und stellt Monosign aus einer einzigen geprüften YAML-Datei als Docker-Swarm-Stacks bereit. Es gibt vier Befehle: | Befehl | Was er tut | | --- | --- | | `monofor check` | Prüft den Server und seine Umgebung. Er ändert nichts. | | `monofor install` | Stellt Monosign bereit. | | `monofor status` | Zeigt den Zustand der Installation. Er liest nur. | | `monofor cert install` | Installiert ein Zertifikat und seinen Schlüssel auf einem bereits installierten System. | Führen Sie zuerst `check` aus und beheben Sie, was gemeldet wird. Wenn der Befehl meldet, dass der Server bereit ist, führen Sie `install` aus. ### Zwei Wege zu beginnen - **Mit einem Installationscode.** Das ist seit v2026.10 der übliche Start: `monofor install --code <CODE>`. Der Code kommt von Ihrem Ansprechpartner bei Monofor und enthält die Einstellungen dieser Installation. `monofor check --code <CODE>` prüft den Server, ohne den Code zu verbrauchen. - **Mit einem Offline-Paket.** Für einen Server in einem isolierten Netz ohne Internetzugang: `monofor install --offline`. Wie Sie beginnen, hat nichts mit der Datenbank zu tun. Darüber entscheidet der Deploy Type. ### PoC oder Produktion | `deployType` | Datenbank | Wofür | | --- | --- | --- | | `poc` | Ein PostgreSQL-Container, den der Installer selbst betreibt | Tests und Labs | | `production` | Eine externe PostgreSQL- oder Microsoft-SQL-Server-Datenbank. Der Installer betreibt keinen Datenbank-Container. | Echte Kunden | ### Was der Kunde vorbereiten muss Der Installer prüft diese drei Dinge, erledigt sie aber nicht: - **DNS-Einträge** für die Hostnamen von Monosign. - **Firewall-Ports** zwischen Benutzern, Server und Datenbank. - **Die externe Datenbank** einer Produktionsinstallation: angelegt, leer und vom Server aus erreichbar. Das Werkzeug stellt außerdem nur Monosign bereit. Monopam und Monosync werden separat installiert, auch wenn der Kunde alle drei gekauft hat. ::diagram msgs-install-plan ### Ein Beispielplan Ein Partner installiert Monosign für ein Krankenhaus. Der Server hat keinen Internetzugang, und das Datenbankteam des Krankenhauses betreibt Microsoft SQL Server. Der Plan, den der Partner eine Woche vorher schickt: 1. Deploy Type `production`, mit einer leeren SQL-Server-Datenbank, die das Datenbankteam vorbereitet. 2. DNS-Einträge für die Hostnamen, beim Netzwerkteam beantragt. 3. Das Offline-Paket, auf den Server kopiert. 4. `monofor check --offline`, bis der Server als bereit gemeldet wird, dann `monofor install --offline`. > Tipp: Schicken Sie dem Kunden die Liste der DNS-Namen, Ports und Datenbankanforderungen deutlich vor dem Installationstag. Der Installer kann einen fehlenden DNS-Eintrag oder eine nicht vorhandene Datenbank nicht beheben; er kann es Ihnen nur melden.

Gruppen, Anmelderichtlinien und externe Identity Provider

Gleich nachdem die erste Anwendung funktioniert, kommen in fast jedem ersten Projekt drei Fragen auf: Wer gehört zu welcher Gruppe, wann soll eine Anmeldung mehr Nachweise verlangen, und können sich Personen mit einem Konto anmelden, das sie anderswo schon haben? ### Gruppen, und wer eine Anwendung erhält Gruppen finden Sie unter Directory → `Groups`. Mitglieder kommen auf einem von zwei Wegen hinein: - **Von Hand**: auf dem Tab `Groups` eines Benutzers, mit `Assign New Group`. - **Per Regel**: eine Regel unter Workflows → `Automation` mit einer Bedingung wie `Department` gleich `Sales` und der Aktion `Assign group(s)`. Die Regel erfasst auch später eingestellte Personen. Ist `Remove access if rule no longer matches` eingeschaltet, nimmt sie die Gruppe wieder weg, wenn jemand in eine andere Abteilung wechselt. Eine Gruppe füllt sich nicht von selbst: Kein Gruppentyp trägt eine eigene Mitgliedschaftsbedingung. Wenn ein Kunde "eine Gruppe mit allen aus Sales" verlangt, lautet die Antwort: eine Gruppe plus eine Automation-Regel. Personen in eine Gruppe aufzunehmen, öffnet ihnen auch noch keine Anwendung. Eine Anwendung wird durch eine **Zuweisung** geöffnet: `Assign a User` auf dem Tab `Assignments` der Anwendung oder die Aktion `Assign application(s)` in einer Automation-Regel. | Der Kunde sagt | Sie konfigurieren | | --- | --- | | "Alle aus Sales gehören zu dieser Gruppe" | Eine Automation-Regel mit `Assign group(s)` | | "Alle aus Sales bekommen das CRM" | Eine Automation-Regel mit `Assign application(s)` | | "Diese drei Personen testen die neue Anwendung" | `Assign a User` an der Anwendung | ### Mehr Nachweise nur von denen verlangen, die sie brauchen Eine Richtlinie vom Typ `Authentication` unter Security → `Policies` hat zwei Teile. Der `Scope` legt fest, für wen sie gilt: eine Regel aus Bedingungen über den Benutzer, zum Beispiel die Mitgliedschaft in einer Gruppe. Der Ablauf auf dem Tab `Actions` legt fest, was die Anmeldung enthalten muss, zum Beispiel einen zweiten Faktor nach dem Passwort. Nur dann mehr zu verlangen, wenn eine Bedingung zutrifft, heißt **Conditional Access**, und hier konfigurieren Sie es in Monosign. Jede Richtlinie hat außerdem eine `Priority` von 1 bis 10, ein optionales `Start Date` und `End Date` sowie einen Schalter `Enabled`. So können Sie eine Richtlinie heute vorbereiten und am nächsten Montag wirksam werden lassen. Beispiel: Ein Kunde möchte den zweiten Faktor zuerst für das Finanzteam, vor dem ganzen Unternehmen. Sie legen eine `Authentication`-Richtlinie an, begrenzen ihren Scope auf die Gruppe `Finance` und fügen ihrem Ablauf einen Schritt für den zweiten Faktor hinzu. Alle anderen melden sich an wie bisher. Die Einführung später auszuweiten heißt, den Scope zu erweitern, nicht die Richtlinie neu zu bauen. ::diagram msgs-policy-scope ### Mit einem Konto von anderswo anmelden Unter Identity → `Providers` definieren Sie **externe Identity Provider**, denen Monosign bei der Anmeldung vertraut. Melden sich die Mitarbeiter eines Kunden bereits mit Microsoft Entra an, wird Entra ein solcher Provider: Der Benutzer wird zu Entra geschickt, meldet sich dort an und kommt bereits verifiziert zu Monosign zurück. Provider werden über SAML 2.0, OpenID Connect oder WS-Federation angebunden, und für verbreitete wie Microsoft Entra, Google und Okta gibt es Vorlagen. Routing-Regeln entscheiden, wer wohin geschickt wird, zum Beispiel alle, deren E-Mail-Adresse auf die Domain des Partners endet. Auf dem Rückweg ordnet Monosign die Person einem vorhandenen Benutzer zu. Ein Benutzer, den es noch nicht gibt, wird nur angelegt, wenn für diesen Provider Just-in-Time-Provisionierung eingeschaltet ist. Verwechseln Sie die beiden Richtungen nicht: | Situation | Wer ist der Identity Provider | | --- | --- | | Das CRM lässt Personen herein, weil Monosign für sie bürgt | Monosign | | Monosign lässt Personen herein, weil Entra für sie bürgt | Entra, und Monosign ist die vertrauende Seite | > Tipp: Bevor Sie eine Richtlinie aktivieren, die alle betrifft, halten Sie ein Administratorkonto aus ihrem Scope heraus, damit ein Fehler in der Richtlinie nicht alle Administratoren aussperren kann.