inforum 1/2007 - Single Sign-On im Web

inforum 1/2007 Inhalt - Vorheriger Artikel - Nächster Artikel - Impressum

Single Sign-On im Web

S. Stoytchev

Was ist (Web-) Single Sign-On und welche Vorteile ergeben sich dadurch?
Single Sign-On (SSO) ist ein Authentifizierungsprozess, der es einem Benutzer ermöglicht, nach einmaliger Eingabe von Authentifizierungsdaten (in den meisten Fällen Benutzername und Passwort) mehrere separate geschützte Anwendungen zu nutzen. In diesem Prozess wird der Benutzer für sämtliche Anwendungen authentifiziert, für die er Zugangsberechtigung besitzt. Damit entfällt während einer Session (engl. für Sitzung) die wiederholte Eingabe von Authentifizierungsdaten.

Im Folgenden betrachten wir die Möglichkeiten für die Realisierung eines Web Single Sign-On – einer speziellen Form von SSO, in der sämtliche Anwendungen webbasiert und nur über einen WWW-Browser genutzt werden.

Bevor wir uns den technischen Details rund um SSO widmen, sollen die wichtigsten Vor- und Nachteile einer solchen Umgebung kurz skizziert werden. Zu den Vorteilen zählen:

  • Höhere Benutzerfreundlichkeit: Die Arbeit wird nicht ständig durch Abfragen von Authentifizierungsdaten unterbrochen. Mit SSO ist die manuelle Eingabe von Authentifizierungsdaten im Idealfall nur einmal erforderlich.

  • Höhere Sicherheit: Oft müssen sich Benutzer viele Passwörter merken – für jede Anwendung ein anderes. In einer SSO-Umgebung können Benutzer ein einziges, dafür aber komplexeres Passwort wählen, was die Sicherheit erhöht.

  • Effektivere Neuentwicklung: SSO stellt ein einheitliches Sicherheitsframework zur Verfügung, so dass Entwickler sich nicht um Authentifizierung kümmern müssen. Sie können bei der Entwicklung neuer Anwendungen auf diese Funktionalität zurückgreifen und darauf vertrauen, dass die Authentizität der Anwender an anderer Stelle sicher und zuverlässig überprüft wird.

Zwei der meist genannten Schwächen von SSO sind:

  • Schwierige und zeitintensive Anpassung bestehender Anwendungen: Die Einbindung von bereits existierenden Anwendungen in eine SSO-Infrastruktur ist in der Regel sehr aufwändig, da meistens eine Anpassung ihrer Sicherheitsmechanismen erforderlich ist. In den Fällen, in denen der Quellcode der Anwendung nicht verfügbar ist, könnte eine solche Anpassung sogar unmöglich sein.

  • Unbeaufsichtigter Arbeitsplatz: Ein „Angreifer“ kann die vollständige Kontrolle über die Anwendungen eines anderen Benutzers übernehmen, wenn letzterer seinen Arbeitsplatz verlässt, ohne sich vorher abzumelden. Obwohl das ein allgemeines Risiko ist, wird dieses durch SSO zusätzlich verschärft, da die fremde Person Zugang zu sämtlichen Anwendungen des Opfers bekommen kann. Im Normalfall (ohne SSO) wäre nur eine Ressource gefährdet.

Fazit: SSO hat durchaus Nachteile, aus Sicht der Endanwender, Dienstanbieter und -entwickler scheinen jedoch die Vorteile zu überwiegen.

Wie kann man SSO realisieren?

Technisch gibt es verschiedene Möglichkeiten, ein Single Sign-On zu realisieren. Hier konzentrieren wir uns auf serverbasierte Lösungen und abstrahieren von solchen, die eine Anpassung der Clienten (z. B. Installation zusätzlicher Software wie Passwort-Safes) erfordern.

Ein wichtiger Begriff, der in diesem Kontext vorab geklärt werden muss, ist der Begriff des digitalen Tickets. Ein Ticket wird bei der Anmeldung erzeugt und dient im Folgenden der Authentifizierung des Benutzers. Technisch ist das Ticket eine Zeichenkette (Identifikationsnummer), mit deren Hilfe der Server die Gültigkeit einer Session automatisiert prüfen kann. Damit der SSO-Mechanismus funktioniert, muss bei jeder Anfrage an den Server dafür gesorgt werden, dass ein gültiges Ticket präsentiert wird. Beim Anwender sind keine lokalen Anpassungen bezüglich ihres Betriebssystems oder der verwendeten Software erforderlich. Tickets werden in Form von Browser-Cookies oder über die Request-URL gespeichert und stehen automatisch Verfügung. Tickets haben in der Regel eine begrenzte Gültigkeit, d. h. wenn ein Ticket abgelaufen ist, muss sich der Benutzer erneut anmelden, um ein neues zu bekommen.

Der sogenannte Circle of Trust ist ein relativ weit verbreiteter Lösungsansatz für ein SSO. Hierbei wird ein Netz aus vertrauenswürdigen Anwendungen aufgebaut. Meldet sich ein Benutzer bei einer der Anwendungen an, so ist er danach für alle anderen Anwendungen gleichermaßen angemeldet. Die ideale Lösung sieht dabei vor, dass der Benutzer bei der Anmeldung am ersten System ein Ticket bekommt, mit dem er sich bei allen anderen Anwendungen authentifizieren kann. Das Ticket muss hierzu bei jeder Anwendung aus dem Circle of Trust verifiziert werden können.

Diese Lösung zeichnet sich durch Einfachheit bei der Implementierung von neuen Anwendungen aus. Ein Nachteil zeigt sich allerdings bei der Anbindung bestehender Anwendungen, deren Sicherheitslogik angepasst werden müsste. Bei solchen Anwendungen, deren Quellcode nicht verfügbar ist, kann die nötige Anpassung nur über den Hersteller gewährleistet werden. Eine weitere Schwäche von Circle of Trust ergibt sich aus der Tatsache, dass potenziell jede Anwendung auf Authentifizierungsdaten des Benutzers zugreifen und diese verarbeiten kann. Daraus könnte ein erhöhter Koordina­tionsaufwand zwischen den Dienstanbietern resultieren. Darüber hinaus erhöht sich mit einer steigenden Anzahl von Anwendungen das Risiko, dass Fehler in einer Anwendung die Sicherheit des gesamten Circle of Trust gefährden könnten.

Der Einsatz eines zentralen Login-Servers könnte die zuletzt angesprochene Schwäche einer SSO-Umgebung entkräften. Bei dieser Lösung – mit einem dedizierten Login- bzw. Ticket-Server – wird eine eigene Anwendung implementiert, die zu Beginn jeder neuen Sitzung angesprochen werden muss. Nach erfolgreicher Anmeldung über diesen Server erhält der Client das Ticket, mit dem er sich gegenüber allen Anwendungen im Verbund authentifizieren kann. Das Ticket muss also vom Client bei jeder Anfrage an eine Anwendung des Verbunds mitgegeben werden, wo eine Überprüfung seiner Gültigkeit vorgenommen wird. Falls das Ticket erfolgreich verifiziert werden konnte, erhält der Benutzer Zugriff auf die Anwendung.

Dieser Ansatz impliziert, dass jede einzelne Anwendung eine spezielle Logik enthalten muss, die das Ticket verifiziert bzw. beim zentralen Ticket-Server verifizieren lässt. Bestehende Anwendungen müssen daher entsprechend dieser Logik angepasst werden, indem die alte Anmeldeprozedur durch einen neuen Ablauf ersetzt wird.

Modell

Offensichtlich erlaubt der Ansatz mit einem zentralen Login-Server die Authentifizierung von der Anwendung zu entkoppeln. Die Verifizierung des Tickets verbleibt jedoch in der Verantwortung der Anwendung. Wünschenswert wäre jedoch eine Lösung, bei der auch diese Funktionalität von der Anwendung abgelöst werden könnte, wodurch ein Anpassungsbedarf nahezu bzw. komplett entfallen würde. Idealerweise sollte eine Lösung so aussehen, dass sowohl die Authentifizierung als auch die Verwaltung (erstellen, verifizieren, löschen, ...) von Tickets außerhalb der Anwendung stattfinden. In einem generischen Modell (s. Abbildung) übernimmt ein Ressource-Manager diese Aufgabe.

Technisch handelt es sich hierbei um ein Reverse-Proxy oder auch Webserver-Modul, welches alle Anfragen an eine geschützte Ressource abfängt und die Gültigkeit des Tickets überprüft. Wenn ein Ticket ungültig ist oder fehlt, wird die Anfrage an den zentralen Login-Server weitergeleitet, wo die Authentifizierung des Benutzers und die Erstellung eines gültigen Tickets erfolgen. Danach kann der Client mithilfe dieses Tickets alle Ressourcen nutzen, die im SSO-Verbund durch Ressource-Manager geschützt sind.

Im Rahmen vom Projekt MIRO [1] wurden zwei Produkte evaluiert, die den gerade beschriebenen Lösungsansatz zur Realisierung von SSO verfolgen: den IBM Tivoli Access Manager for e-Business [2] in Verbindung mit dem Reverse-Proxy WebSeal sowie die Open-Source Lösung Shibboleth [3]. Shibboleth weist aufgrund seiner offenen Schnittstellen, der gebotenen Flexibilität und einer großen Internet-Community viele Vorteile gegenüber der proprietären Lösung von IBM auf. Weiterhin bietet Shibboleth die Möglichkeit, Authentifizierungsdienste auch organisationsübergreifend zur Verfügung zu stellen und wird daher bereits von einigen anderen Universitäten und öffentlichen Einrichtungen getestet bzw. eingesetzt, um in Zukunft auch Dienste im Rahmen einer Föderation bzw. Kooperation anbieten zu können.

Die Rolle des zentralen Login-Servers übernimmt bei Shibboleth ein sogenannter Identity-Provider – eine Webanwendung die für die Authentifizierung und die Erstellung von Tickets verantwortlich ist. Der Identity-Provider kann flexibel in Kombination mit verschiedenen Benutzerdatenbanken (LDAP, ActiveDirectory, Kerberos, ...) eingesetzt werden. Als Ressource-Manager fungieren sogenannte Service-Provider, die technisch als Webserver-Module realisiert sind. Das Zusammenspiel von Identity-Provider und Service-Provider kann anhand der folgenden beispielhaften Sitzung beschrieben werden:

  • Jeder nicht authentifizierte Aufruf eines Benutzer-Clients wird vom Service-Provider zuerst an den Identity-Provider umgelenkt.

  • Nach erfolgreicher Anmeldung erhält der Client vom Identity-Provider ein Ticket und wird mittels einer vorher mitgegebenen Rücksprung-URL zurück zum Service-Provider geleitet. Technisch besteht das Ticket aus einem digital signierten Dokument, das verschiedene benutzerbezogene Informationen (z.B. Benutzername, Rollen, ...) enthält. Das Dokument benutzt die Syntax der Security Assertion Markup Language (SAML) [4].

  • Der Service-Provider überprüft die Signatur des Tickets und liest die darin befindlichen Informationen aus. Der Aufruf des Clients wird erst dann zur geschützten Anwendung weitergeleitet.

Die Benutzerdaten können vom Service-Provider in Form von Umgebungsvariablen (z. B. REMOTE_USER) an die Anwendung zur Verfügung gestellt werden. Somit braucht die Anwendung lediglich diese Umgebungsvariablen auszulesen, um an die benötigten Benutzerdaten zu gelangen und kann sich gleichzeitig darauf verlassen, dass die Authentifizierung des Benutzers erfolgreich stattgefunden hat. Da die Verwendung von Umgebungsvariablen eine häufig eingesetzte Technik ist, machen viele vorhandene Anwendungen Gebrauch davon und müssen nicht aufwändig angepasst werden, um an einem auf Shibboleth basierenden SSO teilzunehmen. Im Fall des Portalservers wurde diese Anpassung bereits vorgenommen, was dank der Erweiterbarkeit von WebSphere problemlos möglich war.

Mit Shibboleth ergibt sich für ein universitätsweites Single Sign-On eine Architektur, die Ähnlichkeiten mit den oben vorgestellten Konzepten des Circle of Trust und des zentralen Login-Servers aufweist. Durch den Einsatz von Shibboleth versprechen wir uns eine höhere Produktivität durch benutzerfreundlichere Gestaltung der Anwendungslandschaft verbunden mit einem relativ geringen Aufwand der Realisierung.

Verweise:

[1] http://www.uni-muenster.de/IKM/miro/

[2] http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/

[3] http://shibboleth.internet2.edu/

[4] http://www.oasis-open.org/specs/index.php#samlv2.0


inforum 1/2007 Inhalt - Vorheriger Artikel - Nächster Artikel - Impressum

Zentrum für Informationsverarbeitung (Universitätsrechenzentrum)