Was hat sich geändert

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

Version 12 → 13

Aktualisierung

Neues Modul zum Betrieb von SSO in der Produktion: Audiences, anwendungsbezogene Signaturzertifikate, Token-Lebensdauern und Profil-Claims, Sitzungsdauer, Abmeldung und Widerruf, Kerberos-Anmeldung, Vereinbarungen und der Anwendungskatalog. Die Lektion zur Föderation behandelt jetzt auch Routing-Konflikte.

4 Lektionen aktualisiert

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

SAML-2.0-Anwendungen

Beim ausgehenden SAML ist **Monosign der Identitätsanbieter (IdP)** und die Anwendung der **Service Provider (SP)**. Die Konfiguration liegt auf einem Anwendungsschlüssel vom Typ `SAML`: Applications → Anwendung → `Keys` → Schlüsselkarte `Configure` → Tab `SAML Settings`. Die Schlüsselkarte liefert auch die Anmelde-URL, die Metadaten und das Zertifikat für den SP. ::diagram saml-sp-initiated Wichtige Einstellungen: - **`Metadata Import`**: XML oder URL eingeben, mit `Preview changes` prüfen und mit `Apply to Configuration` übernehmen. Das füllt Entity-ID, ACS-Endpunkte, NameID-Format, Logout-URL und SP-Zertifikate. Es erfordert einen gespeicherten Schlüssel, und Monosign prüft Anwendungsmetadaten nicht im Hintergrund erneut. - **ACS-URLs**: `Additional Assertion Consumer Urls` ist die Liste der erlaubten Endpunkte. `ACS Validation Mode` ist `Off (Legacy)`, `Warn Only` oder `Enforce`. Ein in der Konsole erstellter Schlüssel beginnt mit `Enforce`, ein vor v2026.07 gespeicherter Schlüssel verhält sich jedoch wie `Warn Only` und sendet an jede angeforderte URL. Nur `Enforce` lehnt ab. Der Abgleich ist exakt, ein abschließender Schrägstrich ergibt also eine andere URL. - **`Name Id` und `NameId Format`**: `Name Id` legt den gesendeten Wert fest (Standard `UserName`, oder eine Profileigenschaft oder ein Token). `NameId Format` ist die Formatangabe, die der SP erwartet. Ist der Wert für einen Benutzer leer, stoppt die Anmeldung mit einem `DATA_MISSING`-Audit. - **Bindings**: SP-initiierte Anmeldung über HTTP-POST und HTTP-Redirect sowie IdP-initiierte Anmeldung, die den Standard-ACS verwendet. Vermeiden Sie HTTP-Artifact hinter einem Load Balancer: Die Artifact-Auflösung wird je Knoten gehalten und schlägt auf einem anderen mit `Unknown artifact` fehl. - **`Signing Algorithm`**: `System Default (SHA 256)` oder SHA-1. Verwenden Sie SHA-1 nur, wenn der SP nichts Besseres kann. - **`Signing Certificates`**: `Organization-Based` (gemeinsam, unter System → `Configurations` festgelegt) oder `Application-Based`. ::shot sso-saml-settings ### Grenzen, die der Kunde kennen sollte - Monosign **verschlüsselt** weder Assertions noch Antworten. `Don't Encrypt Entire Message` und `Don't Encrypt Assertion` sind irreführende Bezeichnungen: Sie entfernen eine **Signatur**, lassen Sie sie also aus, solange der SP es nicht verlangt. - Die Abmeldung von einer Anwendung sendet keinen SAML-`LogoutRequest` an die anderen Anwendungen des Benutzers. > Tipp: Wählen Sie einen `Name Id`-Wert, der sich während der gesamten Lebensdauer des Benutzers nicht ändert. E-Mail-Adressen ändern sich, und die Formatangabe allein schützt Sie nicht.

Claim-Zuordnung und eingehende Identitätsanbieter

### Claim-Zuordnung Jede Anwendung sollte nur die Attribute erhalten, die sie benötigt. Die Tabs befinden sich am Anwendungsschlüssel: - SAML: `Attribute Mapping`, `Group Mapping`, `Role Mapping`, `Permission Mapping`. - OIDC: `Claim Mapping`, `Profile Claim` sowie Tabs für Gruppen-, Rollen-, Berechtigungs- und Ressourcenzuordnung. Die Tabs für Gruppen, Rollen und Berechtigungen sind standardmäßig aus. Jeder hat einen Attributnamen (Standard `Groups`), einen Filter und ein Format (Standard `{{Name}}`). Nutzen Sie den Filter, damit eine Anwendung ihre eigenen Gruppen statt der gesamten Mitgliedschaftsliste erhält. Bei OIDC **ersetzt** eine `Claim Mapping`-Zeile, die nach einem von Monosign selbst ausgestellten Claim wie `email` oder `sub` benannt ist, diesen Claim. ::diagram sso-claim-mapping ::shot sso-providers-list ### Eingehende Föderation Unter Identity → `Providers` kann Monosign auch externen IdPs *vertrauen*. `Add New` bietet Vorlagen für Anbieter wie Microsoft Entra ID, Okta, Google, Apple und GitHub oder einen leeren `SAML 2.0`-, `OpenID Connect`- oder `WS-Federation`-Anbieter. - **Routing**: `Matches any user`, `Matches regex` oder `Matches email domain` leitet einen Benutzer zum Anbieter. Verwenden Sie nicht `Matches user attribute`: Es routet nie. Auch ein direkter Besuch der Anmeldeseite ohne zugrunde liegende Anmeldeanfrage wird nicht geroutet. Passen zwei aktive Anbieter auf dieselbe Domäne, zeigt die Liste `Routing Conflicts Detected`, und nur der erste Treffer wird verwendet: Weisen Sie jeder Domäne genau einen Anbieter zu und bestätigen Sie das Ergebnis unter `Routing Overview` mit `Test Routing`. - **`Access rules`**: werden vor jeder Kontosuche ausgewertet. Der erste Treffer gewinnt, Standard ist `Allow`. - **`Account link policy`**: Standard ist `Auto (match by email)`. `Manual (link only by source key)` lehnt E-Mail-Treffer ab und verhindert so eine Übernahme über einen E-Mail-Claim, setzt aber vorab verknüpfte Konten voraus. - **Just-in-Time-Bereitstellung**: standardmäßig aus. `Enable Just-in-Time provisioning` erstellt den Benutzer bei der ersten Anmeldung mit zugeordneten Feldern und `Default groups`. - **Profilaktualisierung**: Gruppen vom IdP werden bei jeder Anmeldung hinzugefügt, aber nie entfernt. Verlassen Sie sich daher nicht darauf, um Zugriff zu entziehen. - **Zertifikatsrotation**: `Secondary certificate (rotation)` enthält ein zweites vertrauenswürdiges Zertifikat. Mit `Keep in sync from this metadata URL` aktualisiert Monosign die Metadaten stündlich und legt dort ein zweites veröffentlichtes Zertifikat ab. WS-Federation-Metadaten werden nicht automatisch aktualisiert. ::diagram sso-inbound-federation > Bekannte Einschränkung, zuletzt auf v2026.09 geprüft: Das Formular für eingehende Anbieter zeigt `Require PKCE`, `Max clock skew (seconds)`, `Response verification`, `Sign authentication requests` und `Use persistent NameID format`, doch diese Einstellungen haben keine Wirkung. Versprechen Sie sie keinem Kunden.

Fehlerbehebung bei der Föderation

Die meisten Föderationsfehler folgen wenigen Mustern. Gehen Sie sie der Reihe nach durch. ::diagram sso-federation-checks ### Ausgehendes SAML und OIDC 1. **Hat der Benutzer Monosign erreicht?** Reports → `Audit` (Prüfprotokoll) und der Tab `Audits` der Anwendung zeigen Anmeldeereignisse. Die OIDC-Endpunkte schreiben keine eigenen Audit-Einträge, lesen Sie bei einem OIDC-Client daher auch die Account-Logs. 2. **ACS-Abweichung**: Im Log steht `SAML ACS validation failed`. Vergleichen Sie `RequestedUrl` Zeichen für Zeichen mit dem registrierten `Location`, einschließlich abschließender Schrägstriche. 3. **Assertion geht an eine unerwartete URL**: Der Schlüssel steht auf `Warn Only` oder `Off (Legacy)`. Suchen Sie nach `SAML ACS validation warning` und stellen Sie den Schlüssel dann auf `Enforce`. 4. **Redirect- oder Scope-Fehler bei OIDC**: Prüfen Sie `Allowed Redirect URIs` und `Scope` sowie das URL-Präfix im Verhältnis zum Schlüsseltyp. 5. **Der SP kennt den Benutzer nicht**: Prüfen Sie `Name Id` und die Attributzuordnung. `Your Email seems empty…` mit einem `DATA_MISSING`-Audit bedeutet, dass die Eigenschaft für diesen Benutzer leer ist. 6. **Der SP lehnt die Signatur ab**: Vergleichen Sie das Zertifikat in `/saml/{idpId}/Metadata` mit der Kopie beim SP und lesen Sie beide `Don't Encrypt`-Schalter. Fällt nach einer Rotation nur eine Anwendung aus, ist ihr `Signing Certificates`-Typ wahrscheinlich `Application-Based`. 7. **Issuer-Abweichung**: `does not match the configured Entity Id` ist nur eine Warnung. Suchen Sie in derselben Anfrage weiter nach dem eigentlichen Fehler. `Enable Debug Mode` an einem SAML-Schlüssel protokolliert jede Anfrage und Antwort vollständig. Nutzen Sie es kurz und schalten Sie es wieder aus. ### Eingehende Anbieter - **Benutzer werden nicht zum IdP geleitet**: `Routing Overview` → `Test Routing` mit der Adresse ausführen. Achten Sie auf einen inaktiven Anbieter oder `Routing Conflicts Detected`. - **`No matching user found for the federated identity`**: Die Richtlinie ist `Manual` ohne Verknüpfung, oder der E-Mail-Claim ist nicht zugeordnet. `Interactive test` zeigt die Claims und die `Mapped profile preview`, ohne jemanden anzumelden. Jeder mit Bearbeitungsrechten am Anbieter kann ihn ausführen, und er gibt rohe Claims aus. - **SAML schlägt fehl, nachdem der IdP sein Zertifikat erneuert hat**: Prüfen Sie die Spalte `Certificate` und die Zeile `Signing certificate` von `Test connection`. - **Niemand wurde vor dem Ablauf gewarnt**: Monosign schreibt `IDENTITY_PROVIDER_CERTIFICATE_EXPIRING`, aber eine Warnung erreicht Personen nur, wenn Sie einen Webhook oder Trigger daran binden. ::shot sso-provider-attribute-mapping

Audiences, Signaturzertifikate und Token-Lebensdauern

Sobald sich eine Anwendung anmeldet, drehen sich die meisten Folgefragen um wenige Schlüsseleinstellungen. Alle befinden sich am Anwendungsschlüssel: Applications → Anwendung → `Keys` → `Configure`. ::shot sso-application-keys ### SAML: für wen die Assertion bestimmt ist Jede Assertion nennt ihren vorgesehenen Empfänger. Monosign nimmt diesen Wert aus dem Feld `Audience` des Schlüssels. Ist das Feld leer, wird `Entity Id` verwendet, und ist auch dieses leer, der Aussteller der eingehenden Anfrage. Antwortet ein Service Provider mit einem Audience-Fehler, wurde die Assertion für einen anderen Empfänger ausgestellt: Vergleichen Sie `Audience` und `Entity Id` am Schlüssel mit der Entity ID, die der SP erwartet. NameID und Signaturzertifikat spielen bei diesem Fehler keine Rolle. ::diagram sso-saml-audience-source ### SAML: ein Zertifikat für alle oder eines pro Anwendung Ein Schlüssel mit `Organization-Based` signiert mit dem gemeinsamen Organisationszertifikat. Wird dieses Zertifikat rotiert, wechseln alle Anwendungen darauf im selben Moment, sodass alle ihre Service Provider gemeinsam aktualisiert werden müssen. Für einen Service Provider, der nach eigenem Zeitplan rotieren muss, öffnen Sie den Tab `Signing Certificates` und verwenden `Generate New Certificate` (oder `Create to Application-Based Signing Certificate`), speichern den Schlüssel und übergeben dem SP die neuen Metadaten. Von da an berührt eine Rotation des Organisationszertifikats diese Anwendung nicht mehr, und ihr eigenes Zertifikat kann getrennt erneuert werden. Zertifikate, die mit dem Metadatenimport eines SP eintreffen, werden nur zur Information gespeichert. Monosign signiert nicht mit ihnen. ### OIDC: die Audience gehört zum Access Token `Audience` und `Resource` an einem OIDC-Schlüssel werden nur in das **Access Token** geschrieben und bei jedem Refresh erneut gesetzt. Das ID Token behält die `client_id` als `aud`, wie OpenID Connect es vorsieht. Eine API, die ihren eigenen Audience-Wert benötigt, sollte daher Access Tokens validieren, nicht ID Tokens. ### OIDC: Lebensdauern und was ein deaktivierter Benutzer noch tun kann - Die drei Lebensdauerfelder sind in **Minuten** angegeben. Bis v2026.07-hf02 las ein Client mit Client Credentials sie als Sekunden. Ein auf einem solchen Build eingestellter Schlüssel, zum Beispiel `3600` für eine Stunde, stellt nach einem Upgrade auf v2026.09 oder neuer Tokens aus, die 60 Stunden gelten. Prüfen Sie diese Schlüssel beim Upgrade und geben Sie den Wert in Minuten neu ein, hier `60`. - Eine Lebensdauer wird beim Ausstellen eines Tokens angewendet. Bereits ausgestellte Tokens behalten ihr Ablaufdatum. - Das Deaktivieren eines Benutzers ruft ein Access Token nicht zurück. Das Token bleibt bis zu seinem `exp` gültig, und der nächste Refresh wird mit *The refresh token is no longer valid.* abgelehnt. Halten Sie `Access Token Lifetime` für APIs kurz, bei denen dieses Zeitfenster zählt. ### OIDC: nur die Profildaten senden, die der Client braucht Wenn `Profile Access Type` Profil-Claims zulässt, enthält der Profil-Claim **jede** Profileigenschaft, solange Sie ihn nicht einschränken. Wählen Sie im Tab `Profile Claim` unter `Included Properties` nur die Eigenschaften aus, die der Client liest. So bleiben personenbezogene Daten aus den Tokens heraus, und die Tokens bleiben klein genug für Proxys mit Header-Limits. `Included Properties` begrenzt nur das Token. Der Userinfo-Endpunkt gibt weiterhin das vollständige Benutzermodell zurück; prüfen Sie daher, welche Clients ihn aufrufen. > Tipp: Dekodieren Sie nach jeder dieser Änderungen ein Token oder eine Assertion, die **nach** der Änderung ausgestellt wurde. Ein älteres sagt Ihnen nichts.