Single Sign-on

Single Sign-on (SSO, mitunter auch als „Einmalanmeldung“ übersetzt) bedeutet, dass sich ein Benutzer mit bei einem Identity Provider (IDP) zentral abgelegten Logindaten an einem Arbeitsplatz auf alle Rechner und Dienste, für die er lokal berechtigt (autorisiert) ist, vom selben Arbeitsplatz aus zugreifen kann, ohne sich an den einzelnen Diensten mit eigenen Logindaten zusätzlich anmelden zu müssen. Wechselt der Benutzer den Arbeitsplatz, wird die Authentifizierung, wie auch die lokale Autorisierung, hinfällig.

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.

Der Zweck von Single Sign-on ist es, dass sich der Benutzer nur einmal unter Zuhilfenahme eines Authentifizierungsverfahrens (z. B. durch Passworteingabe) authentisieren muss. Bei darauf folgenden Authentifizierungen übernimmt nun der SSO-Mechanismus diese Aufgabe, indem die Authentisierung automatisiert abläuft.

Vor- und Nachteile des Single Sign-on

Generelle Einschränkung bei mobiler Arbeit

  • Wechselt der Benutzer bei mobiler Arbeit den Arbeitsplatz, muss er sich ohnehin am nächsten Arbeitsplatz erneut anmelden.
  • Verlässt der Benutzer bei mobiler Arbeit den Arbeitsplatz, wird er meist über eine Zeitschranke von den bereits erlangten Zugriffen getrennt. Um dies bei Handlungspausen zu vermeiden, sind die Zeitschranken meist recht großzügig ausgelegt. Die Folge ist unweigerlich, dass unbeaufsichtigte Arbeitsplätze unbefugten Dritten hinreichend Zeit und Gelegenheit bieten, dem berechtigten Benutzer bereits gewährte Zugriffe unbefugt weiter zu nutzen.

Vorteile

  • Zeitersparnis, da nur noch eine einzige Authentifizierung notwendig ist, um auf alle Systeme zugreifen zu können
  • Sicherheitsgewinn, da das Passwort nur einmal übertragen werden muss
  • 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
  • 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.
  • Ist eine gleichwertige Sign-off-Lösung nicht definiert, dann bleibt der Zugang bis zur Überschreitung einer „Time-out“-Zeit offen.

Lösungsansätze

Drei Lösungsansätze für Single Sign-on. Links: Benutzer meldet sich auf einem Portal an und bekommt Zugriff auf alle eingebundenen Dienste. Mitte: Der Benutzer speichert alle Anmeldedaten auf einem Datenträger oder im Netzwerk. Ein lokales Programm meldet ihn separat bei jedem Dienst, Portal oder Ticketing-System ein. Rechts: Benutzer meldet sich bei einem der Dienste an und bekommt ein Ticket für den gesamten „Kreis der Vertrauten“.

Medienlösung

Der Benutzer verwendet ein elektronisches Token, das die gesamte Passwortinformation oder mindestens einen Authentisierungsfaktor enthält und diese(n) automatisch an den Arbeitsplatz überträgt:

  • elektronische Schlüsselanzeige mit manueller Tastatureingabe
  • elektronischer Schlüssel mit Kontaktübertragung (USB, 1wire etc.)
  • drahtloser Schlüssel (Bluetooth-Token – Mobiltelefon oder anderes Gerät mit Bluetooth-Funktion)

Portallösung

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

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.

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

  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

Auf dieser Seite verwendete Medien

Single sign on aproaches.svg
Three aproaches to Single Sign On: Left: (Web-)Client logs into a portal, that authenticates him to invoked servers and applications. Right: Client logs into one participant application in a circle of trust and gets a ticket for all of them. Middle: Client stores any login information localy or on a (directory-)server and logs in automated but separatly, even to portals or ticket systems.