Single Sign-On (SSO) einführen: SAML, OIDC und praktische Umsetzung

Warum SSO mehr ist als Bequemlichkeit

Jeder Mitarbeiter in einem durchschnittlichen Unternehmen nutzt zwischen 20 und 40 verschiedene Anwendungen. Ohne Single Sign-On bedeutet das 20 bis 40 verschiedene Passwörter, die gegen jede Passwort-Richtlinie verstoßen, die gemerkt, eingegeben und regelmäßig geändert werden müssen. Die Folge ist vorhersehbar: Passwörter werden wiederverwendet, auf Zetteln notiert oder in unsicheren Dokumenten gespeichert. Jedes einzelne dieser Passwörter ist ein potenzieller Angriffsvektor.

Single Sign-On löst dieses Problem, indem sich Mitarbeiter nur einmal anmelden und dann Zugriff auf alle verbundenen Anwendungen erhalten. Der Identity Provider (IdP) übernimmt die Authentifizierung zentral, und die einzelnen Anwendungen (Service Provider, SP) vertrauen seiner Bestätigung. Das klingt nach einem einfachen Konzept, aber die Umsetzung erfordert eine sorgfältige Planung.

Der Sicherheitsgewinn von SSO geht weit über die Reduzierung von Passwörtern hinaus. Wenn ein Mitarbeiter das Unternehmen verlässt, deaktivierst du ein einziges Konto im Identity Provider und der Zugang zu allen verbundenen Anwendungen wird sofort gesperrt – ein zentraler Baustein des User Lifecycle Managements. Ohne SSO muss die IT-Abteilung jeden einzelnen Account manuell deaktivieren, was Tage dauern kann und in der Praxis oft unvollständig bleibt. Laut einer Studie von Osterman Research behalten 25 Prozent der ehemaligen Mitarbeiter noch Wochen nach ihrem Ausscheiden Zugang zu mindestens einem Unternehmenssystem.

Regulatorisch ist SSO zwar keine explizite Anforderung von ISO 27001 oder NIS2, aber es ist ein zentraler Baustein für die Umsetzung mehrerer Anforderungen. ISO 27001 Annex A.8.5 (sichere Authentifizierung) fordert angemessene Authentifizierungsmechanismen. Annex A.5.18 (Zugangsrechte) verlangt ein kontrolliertes Verfahren für die Vergabe und den Entzug von Zugangsrechten. Beides wird durch SSO erheblich erleichtert.

Die zwei Protokolle: SAML und OIDC

Für die technische Umsetzung von SSO stehen zwei dominante Protokolle zur Verfügung: SAML 2.0 und OpenID Connect (OIDC). Beide erreichen dasselbe Ziel auf unterschiedlichen Wegen, und die Wahl zwischen ihnen hat praktische Konsequenzen für dein Unternehmen.

SAML 2.0: Der Enterprise-Veteran

SAML (Security Assertion Markup Language) wurde 2005 von OASIS standardisiert und ist seitdem der De-facto-Standard für SSO im Enterprise-Umfeld. Das Protokoll basiert auf XML und definiert drei Rollen: den Identity Provider (IdP), der die Identität bestätigt, den Service Provider (SP), der die Anwendung bereitstellt, und den Principal, also den Benutzer.

Der SAML-Ablauf bei einer SP-initiierten Anmeldung funktioniert folgendermaßen: Der Benutzer ruft die Anwendung auf. Die Anwendung erkennt, dass keine gültige Session existiert, und erstellt einen SAML Authentication Request. Dieser Request wird über den Browser an den Identity Provider weitergeleitet. Der IdP authentifiziert den Benutzer (z. B. über Benutzername, Passwort und MFA). Nach erfolgreicher Authentifizierung erstellt der IdP eine SAML Assertion, ein XML-Dokument, das die Identität des Benutzers und seine Attribute enthält. Diese Assertion wird digital signiert und über den Browser an den Service Provider zurückgeleitet. Der SP überprüft die Signatur, extrahiert die Benutzerinformationen und erstellt eine lokale Session.

Die Stärken von SAML liegen in der weiten Verbreitung im Enterprise-Bereich. Praktisch jede größere SaaS-Anwendung unterstützt SAML: Salesforce, ServiceNow, Jira/Confluence, Slack, Zoom und hunderte weitere. Die XML-basierten Assertions ermöglichen die Übertragung umfangreicher Attribut-Informationen, und die Signaturprüfung bietet eine starke kryptografische Absicherung.

Die Schwächen von SAML zeigen sich bei modernen Anwendungsarchitekturen. Das Protokoll wurde für klassische Web-Anwendungen mit serverseitigem Rendering entworfen. Single Page Applications (SPAs), mobile Apps und API-basierte Microservices lassen sich damit nur umständlich anbinden. Die XML-Verarbeitung ist komplex und fehleranfällig, und die SAML-Assertions können mehrere Kilobyte groß werden, was bei mobilen Verbindungen ins Gewicht fällt.

OpenID Connect: Der moderne Standard

OpenID Connect (OIDC) wurde 2014 als Erweiterung von OAuth 2.0 veröffentlicht und adressiert genau die Schwächen von SAML. Während OAuth 2.0 nur die Autorisierung regelt (wer darf was), fügt OIDC eine Authentifizierungsschicht hinzu (wer bist du). Das Protokoll nutzt JSON Web Tokens (JWTs) statt XML und ist damit leichtgewichtiger und einfacher zu implementieren.

Der OIDC-Ablauf bei einem Authorization Code Flow sieht so aus: Der Benutzer ruft die Anwendung auf. Die Anwendung leitet den Browser zum Authorization Endpoint des Identity Providers weiter. Der IdP authentifiziert den Benutzer. Nach erfolgreicher Authentifizierung leitet der IdP den Browser mit einem Authorization Code zurück zur Anwendung. Die Anwendung tauscht diesen Code beim Token Endpoint des IdP gegen ein ID Token (ein JWT mit Benutzerinformationen) und ein Access Token ein. Die Anwendung validiert das ID Token und erstellt eine Session.

Die Stärken von OIDC sind die native Unterstützung moderner Architekturen. SPAs können den Implicit Flow oder den Authorization Code Flow mit PKCE nutzen, mobile Apps verwenden den Authorization Code Flow mit Custom URI Schemes, und Microservices validieren Access Tokens eigenständig, ohne den IdP bei jeder Anfrage kontaktieren zu müssen. JWTs sind kompakt, leicht zu parsen und können zusätzliche Claims enthalten, die für die Autorisierung verwendet werden.

Die Schwächen: OIDC ist im Enterprise-Bereich weniger verbreitet als SAML, obwohl die Akzeptanz schnell wächst. Ältere Enterprise-Anwendungen unterstützen oft nur SAML. Und die Flexibilität des Protokolls führt dazu, dass verschiedene IdPs leicht unterschiedliche Implementierungen liefern, was die Integration manchmal erschwert.

SAML oder OIDC: Eine Entscheidungshilfe

Die Entscheidung zwischen SAML und OIDC ist in der Praxis selten eine reine Entweder-oder-Frage. Die meisten Identity Provider unterstützen beide Protokolle, und du wirst wahrscheinlich beide einsetzen, je nachdem, welches Protokoll die jeweilige Anwendung unterstützt.

Als Faustregel gilt: Wenn du primär SaaS-Anwendungen im Enterprise-Bereich anbindest (Salesforce, ServiceNow, SAP), wirst du überwiegend SAML nutzen, weil diese Anwendungen SAML seit Jahren unterstützen und die Integration gut dokumentiert ist. Wenn du moderne Web-Anwendungen, SPAs, mobile Apps oder eigene Microservices anbindest, ist OIDC die bessere Wahl, weil es für diese Architekturen entwickelt wurde.

Für neue Eigenentwicklungen solltest du grundsätzlich OIDC verwenden. Das Protokoll ist einfacher zu implementieren, die JWT-Bibliotheken sind in allen gängigen Programmiersprachen ausgereift, und die Debugging-Möglichkeiten sind besser, weil du JWTs einfach decodieren und inspizieren kannst, während SAML-Assertions als Base64-codiertes XML deutlich schwerer zu lesen sind.

Den richtigen Identity Provider auswählen

Der Identity Provider ist das Herzstück deiner SSO-Infrastruktur. Er speichert die Benutzeridentitäten, führt die Authentifizierung durch, verwaltet MFA und stellt die Tokens oder Assertions aus. Die Wahl des IdP hat langfristige Konsequenzen, weil eine spätere Migration aufwendig ist.

Microsoft Entra ID (ehemals Azure AD)

Entra ID ist die naheliegende Wahl, wenn dein Unternehmen bereits Microsoft 365 nutzt. Die Benutzerkonten existieren bereits, die Integration mit Office-Anwendungen ist nahtlos, und viele Funktionen sind in den vorhandenen Lizenzen enthalten. Entra ID unterstützt sowohl SAML als auch OIDC, bietet Conditional Access Policies, die den Zugriff auf Basis von Gerätezustand, Standort und Risikobewertung steuern, und integriert sich mit dem lokalen Active Directory über Entra Connect (ehemals Azure AD Connect).

Für SSO mit Drittanbieter-Anwendungen bietet Entra ID einen Enterprise Application Gallery mit vorkonfigurierten Integrationen für tausende Anwendungen. Die Einrichtung reduziert sich oft auf wenige Klicks: Anwendung aus der Gallery auswählen, SAML-Metadaten austauschen und Attribut-Mapping konfigurieren.

Die Lizenzierung ist allerdings ein wichtiger Faktor. Grundlegende SSO-Funktionen sind in Microsoft 365 Business Basic enthalten. Conditional Access, risikobasierte Anmeldung und erweiterte Berichte erfordern Entra ID P1 oder P2, was zusätzliche Kosten pro Benutzer und Monat bedeutet.

Okta

Okta ist ein spezialisierter Identity Provider, der unabhängig von einem bestimmten Ökosystem arbeitet. Das ist ein Vorteil, wenn du eine heterogene Infrastruktur hast, die nicht primär auf Microsoft setzt. Okta bietet einen umfangreichen Integrationskatalog, leistungsstarke Lifecycle-Management-Funktionen und eine entwicklerfreundliche API.

Der Nachteil sind die Kosten. Okta berechnet pro Benutzer und Monat, und die Preise steigen mit erweiterten Funktionen wie Adaptive MFA und Lifecycle Management schnell an. Für ein Unternehmen mit 200 Mitarbeitern können die jährlichen Kosten fünfstellig werden.

Keycloak (Open Source)

Keycloak ist eine Open-Source-Lösung von Red Hat, die du selbst hosten kannst. Das bietet maximale Kontrolle über deine Identitätsdaten, keine laufenden Lizenzkosten und die Möglichkeit, den IdP an deine spezifischen Anforderungen anzupassen.

Die Kehrseite: Du bist für Betrieb, Wartung, Updates und Hochverfügbarkeit selbst verantwortlich. Keycloak ist ein komplexes System, das Expertise in Java, Docker/Kubernetes und Datenbankadministration erfordert. Für Unternehmen ohne dediziertes DevOps-Team kann der Betriebsaufwand die eingesparten Lizenzkosten schnell übersteigen.

Google Workspace

Wenn dein Unternehmen auf Google Workspace setzt, bietet Google eine integrierte SSO-Lösung, die sowohl SAML als auch OIDC unterstützt. Die Integration mit Google-Diensten ist naturgemäß nahtlos, und der Integrationskatalog deckt die gängigen SaaS-Anwendungen ab. Für Unternehmen mit einer primär Google-basierten Infrastruktur ist dies die logische Wahl.

SSO-Einführung planen und umsetzen

Die technische Einrichtung von SSO ist in den meisten Fällen weniger aufwendig als die organisatorische Vorbereitung. Der Erfolg hängt davon ab, wie gründlich du die Anwendungslandschaft inventarisierst, wie klug du die Reihenfolge der Migration wählst und wie gut du die Mitarbeiter vorbereitest.

Phase 1: Anwendungen inventarisieren

Der erste Schritt ist eine vollständige Bestandsaufnahme aller Anwendungen, die in deinem Unternehmen genutzt werden. Dazu gehören nicht nur die offiziell beschafften SaaS-Dienste, sondern auch die Shadow-IT, also die Anwendungen, die Abteilungen eigenständig eingeführt haben.

Für jede Anwendung dokumentierst du folgende Informationen: Name und Zweck der Anwendung, Anzahl der Benutzer, aktuelle Authentifizierungsmethode, Unterstützung für SAML und/oder OIDC, Kritikalität für den Geschäftsbetrieb und den verantwortlichen Ansprechpartner. Diese Informationen bilden die Grundlage für die Priorisierung.

Typische Quellen für die Inventarisierung sind das IT-Asset-Management, die Buchhaltung (SaaS-Rechnungen), Browser-Plugins zur Erfassung besuchter Domains, CASB-Lösungen (falls vorhanden) und Befragungen der Abteilungsleiter.

Phase 2: Priorisieren

Nicht alle Anwendungen müssen gleichzeitig migriert werden. Eine sinnvolle Priorisierung berücksichtigt drei Faktoren: Risiko, Nutzerzahl und Integrationsaufwand.

An den Anfang gehören Anwendungen mit hohem Risiko und großer Nutzerzahl, bei denen die SSO-Integration einfach ist. Das sind typischerweise die großen SaaS-Plattformen wie Microsoft 365, Google Workspace, Salesforce oder Slack. Diese Anwendungen bieten gut dokumentierte SSO-Integrationen, und die Migration hat den größten Sicherheitseffekt, weil sie die meisten lokalen Passwörter eliminiert.

In die zweite Welle kommen Anwendungen mit mittlerem Risiko oder kleinerer Nutzerzahl. Das können Projektmanagement-Tools, HR-Systeme oder Entwicklungsplattformen sein.

Am Ende stehen Anwendungen, die kein SSO unterstützen oder deren Integration besonders aufwendig ist. Für diese Fälle brauchst du eine Übergangsstrategie, die weiter unten beschrieben wird.

Phase 3: Technische Integration

Die technische Einrichtung folgt einem einheitlichen Muster, unabhängig davon, ob du SAML oder OIDC verwendest.

Auf der Seite des Identity Providers legst du die Anwendung an, konfigurierst die Redirect-URLs, das Attribut-Mapping (welche Benutzerinformationen an die Anwendung übermittelt werden) und die Zugriffsberechtigungen (welche Benutzergruppen die Anwendung nutzen dürfen). Auf der Seite der Anwendung hinterlegst du die Metadaten des IdP, die Entity ID, die SSO-URL und das Zertifikat (bei SAML) beziehungsweise die Client-ID, das Client-Secret und den Issuer (bei OIDC).

Bei SAML-Integrationen ist das Attribut-Mapping ein häufiger Stolperstein. Die Anwendung erwartet bestimmte Attribute in der SAML-Assertion (z. B. E-Mail-Adresse, Vorname, Nachname, Gruppenzugehörigkeit), und diese müssen exakt mit den Attributen übereinstimmen, die der IdP liefert. Unterschiedliche Schreibweisen, unterschiedliche Namensformate oder fehlende Attribute sind die häufigste Ursache für Integrationsprobleme.

Teste jede Integration gründlich, bevor du sie für alle Benutzer freigibst. Prüfe den Login-Flow, den Logout-Flow (Single Logout ist bei SAML oft fehleranfällig), die Attributübergabe, die Session-Dauer und das Verhalten bei abgelaufenen Sessions.

Phase 4: Migration und Rollout

Die Migration der Benutzer sollte schrittweise erfolgen. Beginne mit einer Pilotgruppe aus IT-Mitarbeitern, die Probleme selbständig identifizieren und lösen können. Erweitere dann auf eine Pilotgruppe aus einer Fachabteilung, um das Benutzererlebnis aus der Perspektive nicht-technischer Anwender zu testen. Erst wenn beide Pilotgruppen erfolgreich migriert sind, rollst du SSO für alle Mitarbeiter aus.

Während der Migration betreibst du die Anwendung im Parallelbetrieb: Sowohl der lokale Login als auch der SSO-Login funktionieren. Das ist wichtig als Fallback, falls Probleme auftreten. Erst wenn SSO für alle Benutzer stabil läuft, deaktivierst du den lokalen Login.

Kommuniziere den Rollout rechtzeitig und klar. Mitarbeiter müssen wissen, was sich ändert, warum es sich ändert und was sie tun müssen. Eine kurze Schritt-für-Schritt-Anleitung mit Screenshots, die den neuen Login-Flow zeigt, ist wertvoller als eine lange E-Mail mit technischen Erklärungen.

Anwendungen ohne SSO-Support

Nicht alle Anwendungen unterstützen SAML oder OIDC. Ältere On-Premise-Anwendungen, spezialisierte Branchensoftware und manche kleinere SaaS-Dienste bieten nur lokale Authentifizierung mit Benutzername und Passwort. Für diese Fälle brauchst du eine Strategie.

Die erste Option ist ein Enterprise Password Manager, der als SSO-Brücke fungiert. Dienste wie 1Password Business oder Bitwarden Enterprise können so konfiguriert werden, dass sie die Passwörter für nicht-SSO-fähige Anwendungen zentral verwalten und über den Identity Provider freigeschaltet werden. Der Mitarbeiter meldet sich per SSO am Password Manager an und greift dann auf die gespeicherten Credentials zu. Das ist keine ideale Lösung, aber es zentralisiert zumindest die Verwaltung und ermöglicht das Sperren der Passwörter beim Offboarding.

Die zweite Option ist ein SSO-Gateway oder Reverse Proxy, der die Authentifizierung vorschaltet. Lösungen wie Cloudflare Access oder Pomerium setzen einen Authentifizierungslayer vor die Anwendung, der die Identität über den IdP prüft, bevor der Zugriff gewährt wird. Die Anwendung selbst muss dafür kein SSO unterstützen.

Die dritte Option ist die Ablösung der Anwendung. Wenn eine geschäftskritische Anwendung kein SSO unterstützt und keine der Brückenlösungen praktikabel ist, solltest du prüfen, ob ein Wechsel zu einer Alternative mit SSO-Support sinnvoll ist. Diese Entscheidung ist natürlich aufwendig, aber bei der nächsten Lizenzverlängerung oder Version-Upgrade sollte SSO-Fähigkeit ein hartes Auswahlkriterium sein.

SSO und MFA: Warum beides zusammengehört

SSO ohne MFA ist ein gefährliches Konstrukt. Wenn ein einziges Passwort den Zugang zu allen Anwendungen öffnet, dann öffnet ein einziges kompromittiertes Passwort den Zugang zu allen Anwendungen. SSO konzentriert das Risiko auf einen einzigen Authentifizierungspunkt, und dieser Punkt muss entsprechend stark geschützt sein.

Deshalb ist die Einführung von MFA am Identity Provider eine zwingende Voraussetzung für SSO. Jede Anmeldung am IdP muss durch einen zweiten Faktor abgesichert sein, sei es ein TOTP-Code, ein FIDO2-Key oder eine Push-Benachrichtigung. Die meisten Identity Provider bieten integrierte MFA-Funktionen, sodass du keine separate Lösung benötigst.

Conditional Access Policies erweitern diesen Schutz um kontextbasierte Entscheidungen. Du kannst konfigurieren, dass MFA nur bei der ersten Anmeldung auf einem bekannten Gerät im Firmennetzwerk erforderlich ist, aber bei jeder Anmeldung von einem unbekannten Gerät oder aus dem Ausland. Oder dass der Zugriff auf besonders kritische Anwendungen grundsätzlich einen FIDO2-Key erfordert, während für weniger kritische Anwendungen ein TOTP-Code ausreicht.

Diese Kombination aus SSO und risikobasierter MFA bietet das beste Verhältnis aus Sicherheit und Benutzerfreundlichkeit. Die Mitarbeiter melden sich einmal an, der IdP bewertet das Risiko und fordert bei Bedarf zusätzliche Faktoren an, und alle verbundenen Anwendungen vertrauen dieser Authentifizierung.

Single Point of Failure: Hochverfügbarkeit planen

Wenn der Identity Provider ausfällt, können sich die Mitarbeiter an keiner einzigen Anwendung anmelden. Dieser Single Point of Failure ist die Kehrseite der Zentralisierung, und du musst Maßnahmen ergreifen, um dieses Risiko zu beherrschen.

Bei Cloud-basierten Identity Providern wie Entra ID oder Okta liegt die Verantwortung für die Verfügbarkeit beim Anbieter. Beide bieten SLAs von 99,99 Prozent, was etwa 52 Minuten ungeplanter Ausfallzeit pro Jahr entspricht. In der Praxis sind die Ausfallzeiten geringer, aber sie kommen vor. Im März 2023 verursachte ein Entra-ID-Ausfall über mehrere Stunden weltweit Anmeldeprobleme.

Folgende Maßnahmen reduzieren das Risiko: Erstens solltest du lange Session-Laufzeiten konfigurieren, sodass bereits angemeldete Benutzer bei einem kurzen IdP-Ausfall weiterarbeiten können, ohne sich neu anmelden zu müssen. Zweitens brauchst du Break-Glass-Accounts, also lokale Administratorkonten für kritische Systeme, die nicht über SSO laufen und nur im Notfall verwendet werden. Diese Accounts müssen mit starken Passwörtern gesichert, in einem versiegelten Umschlag oder einem Hardware-Safe aufbewahrt und regelmäßig getestet werden. Drittens solltest du für besonders kritische Anwendungen einen Fallback auf lokale Authentifizierung vorsehen, den du im Notfall aktivieren kannst.

Bei selbst gehosteten Identity Providern wie Keycloak bist du zusätzlich für die Infrastruktur verantwortlich. Das bedeutet redundante Server, Datenbankreplikation, Load Balancing und ein getestetes Failover-Verfahren. Der Betriebsaufwand ist erheblich, und du solltest ihn realistisch einschätzen, bevor du dich für eine selbst gehostete Lösung entscheidest.

Just-in-Time Provisioning und SCIM

SSO löst das Authentifizierungsproblem, aber nicht das Provisionierungsproblem. Wenn ein neuer Mitarbeiter beginnt, muss sein Konto in jeder Anwendung angelegt werden. Wenn er die Abteilung wechselt, müssen seine Berechtigungen angepasst werden. Und wenn er das Unternehmen verlässt, müssen alle Konten deaktiviert werden.

Just-in-Time (JIT) Provisioning ist eine Teillösung. Wenn sich ein Benutzer zum ersten Mal über SSO an einer Anwendung anmeldet, erstellt die Anwendung automatisch ein Konto auf Basis der Informationen aus der SAML-Assertion oder dem OIDC-Token. Das spart die manuelle Kontoerstellung, aber es löst nicht das Problem der Deprovisionierung. Wenn du den Benutzer im IdP deaktivierst, kann er sich nicht mehr anmelden, aber sein Konto in der Anwendung existiert weiterhin, mitsamt aller gespeicherten Daten.

SCIM (System for Cross-domain Identity Management) geht einen Schritt weiter. SCIM ist ein Standard für die automatische Provisionierung und Deprovisionierung von Benutzerkonten. Der Identity Provider synchronisiert Benutzerkonten, Gruppenzugehörigkeiten und Attribute automatisch mit den verbundenen Anwendungen. Wenn ein Mitarbeiter im IdP deaktiviert wird, deaktiviert SCIM automatisch seine Konten in allen verbundenen Anwendungen.

Die Unterstützung für SCIM wächst, ist aber noch nicht flächendeckend. Bei der Auswahl von SaaS-Anwendungen solltest du SCIM-Support als Kriterium berücksichtigen, besonders für Anwendungen mit vielen Benutzern oder sensiblen Daten.

SSO-Richtlinie erstellen

Die SSO-Einführung sollte durch eine Richtlinie begleitet werden, die in dein ISMS integriert ist. Diese Richtlinie dokumentiert die verbindlichen Regeln und stellt sicher, dass SSO nicht nur technisch, sondern auch organisatorisch verankert ist.

Folgende Punkte sollte die Richtlinie abdecken: Welche Anwendungen müssen über SSO angebunden werden? Welche Ausnahmen sind zulässig und wie werden sie genehmigt? Welche MFA-Methoden sind am Identity Provider konfiguriert und welche sind für welche Anwendungskategorie erforderlich? Wie werden Break-Glass-Accounts verwaltet, gesichert und getestet? Wie läuft das Onboarding neuer Anwendungen ab? Wer ist für die technische Integration verantwortlich? Wie wird das Offboarding sichergestellt, und in welchem Zeitraum müssen Konten nach dem Ausscheiden deaktiviert werden?

Diese Richtlinie ist gleichzeitig dein Nachweis gegenüber Auditoren, dass du die Zugangskontrollen zentral steuerst und dokumentierst. In ISMS Lite kannst du die SSO-Richtlinie als versioniertes Dokument führen und den Fortschritt der Anwendungsmigration als Maßnahmenplan tracken. Das Tool deckt alle ISMS-Module 500 Euro pro Jahr ab, ohne Seat-Lizenzen.

Session-Management und Logout

Ein oft übersehener Aspekt von SSO ist das Session-Management. Wenn sich ein Benutzer am IdP anmeldet, erhält er eine IdP-Session. Jede Anwendung, die er besucht, erstellt zusätzlich eine lokale Session. Diese Sessions haben unterschiedliche Laufzeiten, und das Zusammenspiel dieser Laufzeiten bestimmt das tatsächliche Sicherheitsniveau.

Die IdP-Session sollte so konfiguriert sein, dass sie nach einer angemessenen Zeit der Inaktivität abläuft. Acht Stunden für den normalen Arbeitsalltag sind ein guter Richtwert. Die lokalen Sessions der Anwendungen können kürzer sein, insbesondere für kritische Anwendungen wie HR-Systeme oder Finanzsoftware.

Single Logout (SLO) ist die Funktion, die beim Abmelden am IdP auch alle lokalen Sessions beendet. In der Theorie ist das ein sauberer Mechanismus. In der Praxis ist SLO bei SAML notorisch fehleranfällig, weil es erfordert, dass alle Service Provider den Logout-Request verarbeiten und bestätigen. Wenn eine Anwendung nicht antwortet oder den Request nicht korrekt verarbeitet, bleibt die lokale Session bestehen.

Bei OIDC ist die Situation etwas besser. Die Spezifikation definiert Front-Channel Logout und Back-Channel Logout, wobei Back-Channel Logout zuverlässiger ist, weil der IdP den Logout direkt an die Anwendung sendet, ohne den Browser als Vermittler zu nutzen.

Unabhängig vom Protokoll solltest du das Logout-Verhalten jeder integrierten Anwendung testen und dokumentieren. Dort, wo SLO nicht zuverlässig funktioniert, sind kurze Session-Laufzeiten der beste Schutz.

Monitoring und Audit-Logging

SSO zentralisiert nicht nur die Authentifizierung, sondern auch das Logging. Der Identity Provider protokolliert jede Anmeldung, jeden fehlgeschlagenen Anmeldeversuch und jede MFA-Abfrage. Diese Logs sind eine wertvolle Datenquelle für die Erkennung von Sicherheitsvorfällen und für Audit-Zwecke.

Konfiguriere Alarme für auffällige Muster: mehrere fehlgeschlagene Anmeldeversuche für denselben Account, Anmeldungen aus ungewöhnlichen geografischen Regionen, Anmeldungen außerhalb der üblichen Arbeitszeiten oder Anmeldungen von unbekannten Geräten. Diese Alarme ermöglichen es dir, potenzielle Angriffe frühzeitig zu erkennen und zu reagieren.

Für die ISMS-Dokumentation ist das zentrale Logging ein großer Vorteil. Statt die Anmeldeprotokolle aus jeder einzelnen Anwendung zusammenzusuchen, hast du eine einzige Datenquelle, die alle authentifizierungsrelevanten Ereignisse enthält. Das vereinfacht sowohl die regelmäßige Überprüfung als auch die Beweisführung bei Sicherheitsvorfällen.

Häufige Fehler bei der SSO-Einführung

Die meisten SSO-Projekte scheitern nicht an der Technik, sondern an der Vorbereitung und Kommunikation. Hier sind die häufigsten Fehler, die du vermeiden solltest.

Der erste Fehler ist eine unvollständige Anwendungsinventur. Wenn du die Hälfte der genutzten Anwendungen nicht kennst, kannst du sie nicht anbinden, und die Mitarbeiter behalten ihre lokalen Passwörter. Der Sicherheitsgewinn von SSO ist nur so groß wie der Anteil der angebundenen Anwendungen.

Der zweite Fehler ist SSO ohne MFA. Wie bereits beschrieben, konzentriert SSO das Risiko auf einen einzigen Anmeldepunkt. Ohne MFA wird dieser Punkt zum attraktivsten Ziel für Angreifer.

Der dritte Fehler ist die Vernachlässigung des Offboardings. SSO erleichtert das Offboarding erheblich, aber nur wenn du einen definierten Prozess hast, der sicherstellt, dass das IdP-Konto zeitnah deaktiviert wird. Ohne diesen Prozess ist SSO beim Offboarding nicht besser als separate Accounts.

Der vierte Fehler ist das Fehlen von Break-Glass-Accounts. Wenn der IdP ausfällt und du keinen alternativen Zugang zu kritischen Systemen hast, stehst du vor einem vollständigen Stillstand.

Der fünfte Fehler ist die mangelnde Kommunikation. Mitarbeiter, die plötzlich einen neuen Login-Flow sehen, ohne vorher informiert worden zu sein, werden verunsichert, rufen den Helpdesk an und erzeugen unnötigen Aufwand. Eine klare Vorankündigung mit Termin, Anleitung und Ansprechpartner verhindert das.

Der Weg zum erfolgreichen SSO

Die Einführung von SSO ist kein Wochenendprojekt, aber auch kein Mammutprojekt. Für ein Unternehmen mit 100 bis 500 Mitarbeitern und 20 bis 50 Anwendungen ist ein Zeitrahmen von drei bis sechs Monaten realistisch, von der Inventarisierung bis zur vollständigen Migration.

Beginne mit der Inventarisierung deiner Anwendungen. Wähle einen Identity Provider, der zu deiner bestehenden Infrastruktur passt. Binde die wichtigsten Anwendungen zuerst an und arbeite dich schrittweise durch die Liste. Aktiviere MFA am IdP vom ersten Tag an. Dokumentiere alles in deinem ISMS und nutze die Chance, gleichzeitig dein Berechtigungskonzept zu überarbeiten.

SSO ist mehr als eine technische Maßnahme. Es ist eine organisatorische Veränderung, die das Zusammenspiel zwischen IT, HR und den Fachabteilungen verbessert. Wenn du es richtig machst, gewinnst du nicht nur Sicherheit, sondern auch Effizienz und Transparenz.

Weiterführende Artikel

• Multi-Faktor-Authentifizierung (MFA) einführen: Strategie, Rollout und Akzeptanz
• Berechtigungskonzept erstellen: Vom Rollenmodell bis zur Rezertifizierung
• User Lifecycle Management: Onboarding, Rollenänderung, Offboarding
• Active Directory absichern: Härtung, Tiering und Monitoring
• Zero Trust im Mittelstand: Prinzipien, Quick Wins und Stolperfallen