Single Sign-on (SSO, mitunter auch als „Einmalanmeldung“ übersetzt) bedeutet, dass ein Benutzer mit bei einem Identity Provider (IDP) zentral abgelegten Logindaten auf alle Rechner und Dienste, für die er berechtigt ist, zugreifen kann, ohne sich an den einzelnen Diensten mit eigenen Logindaten zusätzlich anmelden zu müssen.
Für den Anwender bringt diese Möglichkeit insbesondere bei Portalen gewisse Vorteile.[1] Innerhalb von Portalen ist es auch möglich, dass die Identität des angemeldeten Benutzers an die das Portal konstituierenden Schichten weitervererbt wird, ohne dass dies der Sicht des Anwenders selbst bekannt gemacht worden wäre.
Bei Single Sign-on authentifiziert sich der Nutzer nur beim Identity Provider, der auch die Berechtigungen des Nutzers prüft. Bei erfolgreicher Authentifizierung und passenden Berechtigungen wird dem Nutzer ein Token ausgestellt, das den Zugang zu einem oder mehreren Diensten ermöglicht.
Vor- und Nachteile des Single Sign-on
Vorteile
- Sicherheitsgewinn, da sich der Nutzer anstelle einer Vielzahl meist unsicherer Passwörter nur noch eines merken muss, somit kann dieses eine Passwort dafür komplex und sicher gewählt werden
- Phishing-Attacken werden erschwert, da Anwender ihren Benutzernamen und Passwort nur an einer einzigen Stelle eingeben müssen und nicht mehr an zahlreichen, verstreuten Stellen. Diese eine Stelle kann leichter auf Korrektheit (URL, SSL-Serverzertifikat etc.) überprüft werden
- IT-Sicherheitsmaßnahmen können auf den Identity Provider fokussiert werden, da die Logindaten nur noch dort vorliegen müssen
- Es wird Bewusstsein geschaffen, wo man guten Gewissens Nutzername und Passwort eingeben kann. Benutzer eines Single-Sign-on-Systems werden schwerer dazu verleitet, fremden Seiten ihr (möglicherweise mehrfach benutztes) Passwort anzuvertrauen.
Nachteile
- Die Verfügbarkeit des Dienstes hängt nicht nur von der eigenen Verfügbarkeit, sondern auch von der Verfügbarkeit des Single-Sign-on-Systems ab.
- Die erhöhte Abhängigkeit von einem zentralen Identitätsanbieter. Wenn dieser nicht verfügbar ist, können Benutzer möglicherweise nicht auf die Dienste zugreifen, selbst wenn sie ansonsten betriebsbereit sind. Dies betont die Bedeutung einer zuverlässigen Infrastruktur und eines robusten Service-Level-Agreements (SLA) mit dem Identity Provider.
Lösungsansätze
Portallösung
Die Portallösung ermöglicht es dem Benutzer, sich einmalig in einem Portal anzumelden, wo er authentifiziert und pauschal autorisiert wird. Dies bedeutet, dass er ein Identifikationsmerkmal erhält, das ihn innerhalb des Portals eindeutig identifiziert. Bei Portalen, die auf Web-Protokollen basieren, erfolgt dies oft durch die Verwendung von HTTP-Cookies. Sobald der Benutzer sich im Portal angemeldet hat, erhält er Zugang zu mehreren integrierten Webanwendungen, ohne sich separat für jede Anwendung anmelden zu müssen. Bekannte Beispiele für Portale, die dieses System verwenden, sind Yahoo und MSN (Passport).
Ticketing System
Das Ticketing System bietet eine alternative Methode zur Authentifizierung und Autorisierung von Benutzern. Hierbei wird ein Netzwerk aus vertrauenswürdigen Diensten aufgebaut, die entweder eine gemeinsame Identifikation für den Benutzer haben, die sie untereinander austauschen, oder dem angemeldeten Benutzer wird ein virtuelles Ticket zugewiesen. Die erste Anmeldung erfolgt an einem System innerhalb dieses „Circle of Trust“, das dann den Zugriff auf die anderen vertrauenswürdigen Systeme ermöglicht. Bekannte Beispiele für diese Art von Ticketing-Systemen sind Kerberos und das Liberty Alliance Project.
Token System
Das Token System bei Single Sign-on (SSO) mit OAuth oder SAML leitet den Benutzer zur Anmeldung bei einem Identitätsanbieter weiter. Dort authentifiziert sich der Benutzer mit seinen SSO-Anmeldedaten. Wenn die Berechtigung für den Dienst vorliegt, sendet der Identitätsanbieter ein Zugangstoken an den Benutzer, das den Zugriff auf den Dienst ermöglicht.
Lokale Lösung
Benutzer können auch auf ihrem regelmäßig benutzten Arbeitsplatz einen Client installieren, welcher erscheinende Anmeldemasken sofort mit dem richtigen Benutzernamen und dem richtigen Passwort automatisch ausfüllt. Damit wird die Authentisierung geschwächt, soweit keine weiteren Faktoren abgefragt werden.
Dazu muss die Maske vorher trainiert oder definiert worden sein. Beim Training der Maske muss darauf geachtet werden, dass diese auch zweifelsfrei zugeordnet wird. Es muss sichergestellt werden, dass eine nachgemachte bzw. ähnliche Maske nicht fälschlicherweise bedient wird, sonst könnten über diesen Weg sensible Anmeldedaten „abgegriffen“ werden.
Realisiert wird diese zweifelsfreie Erkennung heute oft über zusätzliche Merkmale wie Aufrufpfade, Erstelldatum einer Maske etc., die ein Fälschen einer Maske erschweren.
Die Benutzernamen und Passwörter können als Faktoren
- in einer verschlüsselten Datei lokal auf dem PC,
- auf einer Chipkarte,
- oder auf Single-Sign-on-Anwendungen oder auf Single-Sign-on-Servern im Netzwerk
aufbewahrt werden. Ebenfalls ist es möglich, diese Daten in einen Verzeichnisdienst oder eine Datenbank auszulagern. Beispiele sind die in vielen modernen Browsern integrierten „Passwort-Manager“, Microsofts Identity Metasystem,[2] sowie viele kommerzielle Produkte. Dieser Ansatz wird zumeist bei unternehmens- bzw. organisationsinternen Single-Sign-on-Lösungen verfolgt, da oft proprietäre Anwendungen nicht mit Ticketing oder Portal-Lösungen verwendet werden können.
Siehe auch
Einzelnachweise
- ↑ Jens Fromm: No-Government. In: Mike Weber (Hrsg.): ÖFIT-Trendschau: Öffentliche Informationstechnologie in der digitalisierten Gesellschaft. Kompetenzzentrum Öffentliche IT, Berlin 2016, ISBN 978-3-9816025-2-4 (oeffentliche-it.de [abgerufen am 12. Oktober 2016]).
- ↑ msdn.microsoft.com