Um den vielen Passwörter, und dem damit einhergehenden Problem Herr zu werden, gibt es Single Sign On (vgl.: SSO). SSO beschreibt eine Identitätslösung, die es mehreren Anwendungen ermöglicht, dieselbe Authentifizierungssitzung zu verwenden, wodurch sich die Eingabe von sich wiederholenden Anmeldeinformationen vermeiden lässt. SSO Implementierungen werden von Organisationen als Teil ihrer Strategie zur Sicherung des Zugangs zu wichtigen Ressourcen eingesetzt. Mit dem Aufkommen von Cloud Computing und dem Boom von Software as a Service (vgl.: SaaS) konzentrieren sich Organisationen immer mehr auf Zugriffsmanagementstrategien, die sowohl die Sicherheit als auch die Benutzbarkeit – positive Erfahrung von Benutzern – , verbessern können; die Implementierung von SSO kann beide Aspekte erfüllen.
Aus Sicherheitssicht besteht ein Vorteil von SSO darin, dass weniger Anmeldeinformationen verloren gehen können oder gestohlen werden können, da es die Anzahl der Anmeldeinformationen reduziert, da für die Anmeldung bei mehreren Diensten nur eine einzige Anmeldeinformation erforderlich ist. Darüber hinaus wird Multi-Faktor-Authentifizierung (MFA) oder Zwei-Faktor-Authentifizierung (2FA) in der Regel erzwungen, um diese einzelne, aber umfassende Anmeldeinformation, zu schützen.
Aus Sicht des Endbenutzers verbessert die Nutzung eines Identity Provider (vgl.: IdP) Systems, das SSO unterstützen kann, die Benutzbarkeit, da es die ermüdende Eingabe von Anmeldeinformationen drastisch senkt. Darüber hinaus bedeutet die Verwendung von SSO, dass die Last, sich Anmeldeinformationen für möglicherweise Dutzende von Konten zu merken, beseitigt wird.
Ein positiver Nebeneffekt der Einführung von SSO-Lösungen ist, dass auch die Anzahl der Helpdesk-Anrufe im Zusammenhang mit Aktivitäten zum Zurücksetzen von Passwörtern abnimmt.
Die Umsetzung von Single-Sign On besteht in der Regel darin, einen zentralen Dienst für die Verwaltung der Identitäten zu verwenden, auf den sich Anwendungen verlassen, wenn sich ein Benutzer anmeldet. Wenn bei diesem Ansatz ein nicht authentifizierter Benutzer – hier im Sinn von nicht angemeldet – eine Anwendung öffnet, beziehungsweise anfordert, die nur für angemeldete Benutzer zulässig ist, leitet die betreffende Anwendung den Benutzer an diesen zentralen Dienst weiter. Auf diesem Server authentifiziert sich der Benutzer dann und wird mit Identitätsinformationen zurück zur ursprünglichen Anwendung umgeleitet. Dort kann der Benutzer dann weitermachen und sein ursprüngliches Vorhaben umsetzen.
Wenn derselbe Benutzer nach einer Weile zu einer anderen Anwendung wechselt, die auch Identitätsinformationen benötigt und denselben zentralen Dienst für die Benutzerverwaltung verwendet, um die Benutzerauthentifizierung durchzuführen, kann die zweite Anwendung die bestehende Sitzung nutzen, die der Benutzer bei der Anmeldung bei der ersten Anwendung initiiert hat.
Ein gutes Beispiel, das veranschaulichen kann, wie SSO funktioniert, ist Microsoft (auch natürlich Google, Facebook etc.) und seine verschiedenen Dienste. Wenn du beispielsweise versuchst, auf den Onlinedienst Outlook.com zuzugreifen, ohne authentifiziert zu sein, leitet Microsoft dich zu einem zentralen Dienst um, der unter login.microsoftonline.com gehostet wird. Dort siehst du ein Anmeldeformular, in dem du deine Anmeldeinformationen für deinen Benutzer eingeben musst. Wenn der Authentifizierungsprozess erfolgreich ist, leitet Microsoft dich zu Outlook.com weiter, wo du Zugriff auf dein E-Mail-Konto erhältst. Wenn du dich dann nach der Authentifizierung an diesen zentralen Dienst zu einem anderen Dienst (wie Office365, Azure etc) wendest, wirst du sehen, dass du automatisch angemeldet bist. Hier melde ich mich bei meinem VPN an. Das Azure Active Directory ist in dem Fall mein IdP. In meinem Browser sind aktuell zwei Azure Benutzer angemeldet. Benutze ich einen angemeldeten Benutzer, dann brauche ich nichts weiter zu tun und die Anwendung startet für meinen Benutzer. Wenn ich ein anderes Konto verwende, dann muss ich mich zumindest einmal gemäß der AD Richtlinie anmelden. Das ist dann in der Regel eine zwei Faktor Authentifizierung Methode, wie zum Beispiel mit Benutzernamen und Passwort auf der einen Seite und Bestätigung und Freigabe durch den Microsoft Authenticator auf der anderen Seite.
Ein Bild spricht mehr als tausend Worte, darum die nachfolgende Grafik, um dem SSO Authentifizierungsprozess zu veranschaulichen.
Angenommen, der Benutzer möchte auf domain1.com zugreifen und muss sich anmelden, dann wird er zur Domäne des Authentifizierungsserver domain3.com weitergeleitet, wo er sich authentifiziert. Nach erfolgreicher Authentifizierung speichert domain3 ein Sitzungscookie, das für den SSO-Eintrag verwendet wird. Anschließend setzt der Authentifizierungsserver eine Umleitung mit einem Artefakt für den Browser zurück auf domain1.com. Das Artefakt kann domain1.com gegen einen eigenen Token austauschen, der verwendet werden kann, um die Identität des Benutzers für den nachfolgenden Zugriff auf die Dienste von domain1.com nachzuweisen.
Wenn der Benutzer (in derselben Browser Sitzung) auf domain2.com zugreift, leitet domain2.com zur Authentifizierung auf domain3.com um. Da domain3.com jedoch einen Datensatz hat, dass der Benutzer eine Anmeldesitzung (über das Cookie) hat, muss sich der Benutzer nicht interaktiv anmelden, sondern der Browser wird wie zuvor mit einem entsprechenden Authentifizierungsartefakt zurück zu domain2.com umgeleitet.
Beachte aber, dass der gültige Zeitraum der SSO-Sitzung vom Authentifizierungsserver (domain3.com) festgelegt wird und je nach Sicherheitsrichtlinie und Anforderungen an die Benutzbarkeit einfach so lange wie die Browsersitzung oder für einen bestimmten Zeitraum von Stunden bis Wochen bestehen kann.
So funktioniert SSO grundsätzlich, bei Microsoft wie auch bei allen anderen. Das Protokoll zwischen dem Authentifizierungsserver und den Clientanwendungen ist in der Regel SAML 2.0, OpenID Connect, Kerberos oder ein anderes Authentifizierungsprotokoll, das SSO unterstützt.
