Was ist Single Sign-On?

Einfach erklärt

Mit Single Sign-On melden sich Ihre Mitarbeitenden einmal an und kommen damit in viele weitere Programme: Ticketsystem, Wiki, Zeiterfassung. Das zentrale Konto kann zum Beispiel das Microsoft-365-Konto sein. Man kann es sich wie einen Werksausweis vorstellen. Statt für jede Tür einen eigenen Schlüssel zu verwalten, prüft der Empfang einmal, wer Sie sind. Jede Tür vertraut danach diesem Ausweis.

Warum das für Ihren Betrieb wichtig ist

• Ein Konto statt vieler Passwörter. Die Zwei-Faktor-Anmeldung des zentralen Kontos gilt dann für alle angebundenen Programme.
• Ein Austritt, eine Sperre. Sie sperren ein Konto, nicht zehn. Vergessene Zugänge in einzelnen Programmen werden seltener.
• Ein Überblick. An einer Stelle sehen Sie, wer sich wann bei welchem Programm angemeldet hat.

Was Sie tun können

Fragen Sie bei jeder neuen Software, ob sie die Anmeldung über SAML oder OpenID Connect unterstützt, die beiden üblichen Standards dafür. Prüfen Sie auch, ob das in Ihrem Tarif enthalten ist. Ihr IT-Dienstleister verbindet das Programm dann mit Ihrem zentralen Konto. Nutzt Ihr Betrieb Microsoft 365, bietet sich dafür der Microsoft-365-Mandant an. Auch Open-Source-Programme lassen sich anbinden, das Ticketsystem Zammad etwa über SAML oder OpenID Connect.

Achtung: Mit Single Sign-On hängt vieles an einem Konto. Dieses Konto braucht deshalb den besten Schutz, am besten Passkeys oder einen Sicherheitsschlüssel.

Was Single Sign-On nicht leistet

Single Sign-On regelt die Anmeldung, nicht die Rechte im Programm. Wer was sehen darf, legen Sie weiterhin über Rollen und Rechte fest. Ein Programm, das zusätzlich eigene Passwörter erlaubt, bleibt über diesen Nebeneingang erreichbar, auch wenn das zentrale Konto gesperrt ist.

Rollen und Protokolle

Beteiligt sind zwei Seiten: ein Identity Provider (IdP) wie Microsoft Entra ID oder Keycloak und die Anwendung als Service Provider (SAML) oder Relying Party (OpenID Connect). Die Anwendung vertraut signierten Aussagen des IdP über die Identität des Benutzers.

• SAML 2.0 (OASIS): XML-Assertions, meist per HTTP-POST-Binding über den Browser übergeben und mit dem Schlüssel des IdP signiert.
• OpenID Connect Core 1.0 (OpenID Foundation): Identitätsschicht auf OAuth 2.0 (RFC 6749). Der IdP liefert ein signiertes ID Token im JWT-Format (RFC 7519). Endpunkte und Schlüssel veröffentlicht er im Discovery-Dokument.
• SCIM 2.0 (RFC 7643, RFC 7644): legt Konten in der Anwendung an, ändert und entfernt sie. Single Sign-On allein deprovisioniert nicht.

Der IT-Grundschutz empfiehlt in ORP.4.A18 einen zentralen netzbasierten Authentisierungsdienst, sorgfältig geplant und mit dokumentierten Sicherheitsanforderungen.

Typische Fehler

• Lokale Anmeldung bleibt offen. Die Anwendung akzeptiert weiter Benutzername und Passwort. Gesperrt ist dann nur der Zugang über den IdP.
• Keine Deprovisionierung. Ohne SCIM oder festen Ablauf bleiben Konten in der Anwendung bestehen. API-Tokens dieser Konten können weiter funktionieren.
• Zu breite Zuweisung. In Entra ID steht eine registrierte Anwendung standardmäßig allen Benutzern des Mandanten offen. Mit „Zuweisung erforderlich“ in den Eigenschaften der Unternehmensanwendung gilt sie nur für zugewiesene Benutzer und Gruppen.
• Eigene SAML-Implementierung. Fehler in der Signaturprüfung, etwa bei XML Signature Wrapping, lassen gefälschte Assertions durch. Geprüfte Bibliotheken verwenden.
• Ablaufendes Signaturzertifikat. Läuft das SAML-Zertifikat des IdP ab und wurde es in der Anwendung nicht rechtzeitig getauscht, scheitert jede Anmeldung zum Stichtag.

Prüfen

Das Discovery-Dokument eines OpenID-Connect-IdP abrufen, hier für Entra ID:

curl -s https://login.microsoftonline.com/ihre-firma.de/v2.0/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .jwks_uri'

Für SAML zeigen Browsererweiterungen wie SAML-tracer die übertragene Assertion mit Attributen, Zielgruppe (Audience) und Gültigkeit (NotOnOrAfter). Zusätzlich prüfen: Lässt sich die Anwendung noch mit einem lokalen Passwort öffnen?