Single Sign-On (SSO)

Single Sign-On (SSO) verlagert die Authentifizierung aus den einzelnen Fachanwendungen in einen zentralen Identity Provider (IdP). Meldet sich eine Person dort einmal an, stellt der IdP den angebundenen Anwendungen – den Service Providern beziehungsweise Relying Parties – ein signiertes Token über die erfolgte Authentifizierung aus. Technisch dominieren zwei offene Standards: SAML 2.0, das XML-basierte Assertions über Browser-Redirects oder POST-Bindings überträgt und vor allem in klassischen Unternehmensanwendungen verbreitet ist, sowie OpenID Connect (OIDC), eine auf OAuth 2.0 aufsetzende Schicht, die JSON Web Tokens verwendet und sich für Web-, Mobile- und API-Szenarien durchgesetzt hat. Beide Verfahren übertragen keine Passwörter an die Zielanwendung, sondern nur eine überprüfbare Aussage über die Identität und – je nach Konfiguration – zusätzliche Attribute wie Gruppen- oder Rollenzugehörigkeit.

Aus Sicht der Informationssicherheit ist SSO in erster Linie ein Hebel für Zugriffskontrolle und Nachvollziehbarkeit. Passwörter existieren nur noch an einer Stelle, wodurch Passwort-Wiederverwendung und lokale Passwortspeicher in Fachanwendungen entfallen. Starke Authentifizierung – insbesondere phishing-resistente Multi-Faktor-Authentifizierung nach FIDO2/WebAuthn – muss nur einmal implementiert und gepflegt werden und wirkt dann für alle angebundenen Systeme. Ebenso lassen sich Joiner-Mover-Leaver-Prozesse zentral steuern: Wird ein Konto im Verzeichnisdienst deaktiviert, verliert die Person den Zugang zu sämtlichen angebundenen Anwendungen. Damit unterstützt SSO unmittelbar die Anforderungen an Zugangskontrolle und Identitätsmanagement, die Art. 21 Abs. 2 der NIS2-Richtlinie, ISO/IEC 27001 (A.5.15 bis A.5.18, A.8.5) und der BSI IT-Grundschutz-Baustein ORP.4 an Einrichtungen stellen.

Die Bündelung erzeugt jedoch auch ein konzentriertes Risiko: Der Identity Provider wird zum Single Point of Failure und zum lohnenden Angriffsziel. Fällt er aus, ist der Zugang zu allen angebundenen Anwendungen blockiert; wird ein privilegiertes IdP-Konto oder ein Signaturschlüssel kompromittiert, kann ein Angreifer sich gegenüber sämtlichen Service Providern als beliebiger Benutzer ausgeben. Typische Angriffsmuster sind der Diebstahl gültiger Sitzungs-Token, MFA-Fatigue-Angriffe, die Manipulation von Metadaten oder Signaturprüfungen sowie die missbräuchliche Registrierung eigener Anwendungen im IdP. Angemessene Gegenmaßnahmen sind gehärtete und redundant ausgelegte IdP-Infrastrukturen, striktes Privileged-Access-Management für Administratoren, sauberes Schlüsselmanagement mit regelmäßigem Rollover, kurze Token-Laufzeiten samt Single Logout, lückenlose Protokollierung der Authentifizierungsereignisse in ein SIEM sowie dokumentierte Notfallzugänge (Break-Glass-Konten) für den Ausfall des Identity Providers.