Single Sign-on

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Single-Sign-On)
Zur Navigation springen Zur Suche springen

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, dass den Zugang zu einem oder mehreren Diensten ermöglicht.

Vor- und Nachteile des Single Sign-on[Bearbeiten | Quelltext bearbeiten]

Vorteile[Bearbeiten | Quelltext bearbeiten]

  • 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[Bearbeiten | Quelltext bearbeiten]

  • 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.

Lösungsansätze[Bearbeiten | Quelltext bearbeiten]

Portallösung[Bearbeiten | Quelltext bearbeiten]

Der Benutzer kann sich in einem Portal erstmals anmelden und wird dort authentifiziert und pauschal autorisiert. D. h., er bekommt ein Merkmal, das ihn gegenüber den innerhalb des Portals integrierten Anwendungen eindeutig ausweist. Bei Portalen, die auf Web-Protokollen basieren, kann dies zum Beispiel in Form eines HTTP-Cookies erfolgen. Auf dem Portal erhält dann der Benutzer so Zugang zu mehreren Webanwendungen, bei denen er sich nicht mehr separat anzumelden braucht. Beispiele sind Yahoo oder MSN (Passport).

Ticketing System[Bearbeiten | Quelltext bearbeiten]

Alternativ kann auch ein Netz aus vertrauenswürdigen Diensten aufgebaut werden. Die Dienste haben eine gemeinsame Identifikation für den einen Benutzer, die sie gegenseitig austauschen, oder dem angemeldeten Benutzer ist ein virtuelles Ticket zugeordnet. Die erste Anmeldung erfolgt an einem System aus diesem „Circle of Trust“, der Zugriff auf die anderen vertrauenswürdigen Systeme wird vom zuerst angesprochenen System ermöglicht. Beispiele dafür sind Kerberos sowie das Liberty Alliance Project.

Token System[Bearbeiten | Quelltext bearbeiten]

Beim Single Sign-on mit OAuth oder SAML wird der Nutzer zur Anmeldung in einem Dienst zum Identity Provider weitergeleitet. Dort authentifiziert er sich mit seinen SSO Logindaten und wenn die Berechtigung für den Dienst vorliegt wird ein Zugangstoken an den Nutzer gesendet, mit dem der Zugriff auf den Dienst möglich ist.

Lokale Lösung[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. 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]).
  2. msdn.microsoft.com