Eine Übersicht

Single-Sign-On-Systeme

Bruce Sams

Heutzutage ist es üblich, dass Benutzer täglich mit zehn oder mehr unterschiedlichen IT-Systemen interagieren. In den meisten Fällen müssen sie sich an jedem System gesondert anmelden – eine unbefriedigende Tatsache die nicht nur die Kosten in die Höhe treibt, sondern auch die Produktivität vermindert und Sicherheitsschwachstellen erzeugt. Durch Single-Sign-On-(SSO) Systeme ist es möglich, sich einmal gegen ein zentrales System zu authentifizieren und transparent von anderen Systemen als authentifizierter Benutzer erkannt zu werden. Dieser Artikel beschreibt die wichtigsten Merkmale von SSO-Systemen für Webanwendungen. Es werden drei Open-Source-SSO-Systeme miteinander verglichen.

In einer typischen „Multiple-Sign-On-“ (MSO) Umgebung startet ein Benutzer eine Sitzung in einer primären Domäne, üblicherweise das Betriebssystem seiner Work-Station. Ab diesem Zeitpunkt ist der Benutzer authentifiziert und sein Sicherheitsprofil (Zugriffsrechte auf dem lokalen Rechner) wurde eingerichtet. Von dieser Plattform aus kann der Benutzer nun auf Dienste in anderen Sicherheitsdomänen zugreifen, welche im Weiteren „sekundäre“ Domänen genannt werden. Im Normalfall gibt es viele unterschiedliche sekundäre Domänen und jede verfügt über eigene Rollen und damit verbundene Benutzerrechte.

Abb. 1: Multiple Sign-On (MSO)

Möchte man nun einen Dienst aus einer sekundären Domäne nutzen, ist normalerweise eine separate Authentifizierung nötig, da die primäre Domäne ein unterschiedliches Sicherheitsprofil mit anderen Benutzernamen und Kennworten verwendet. Beispielsweise muss ein Anwender, der sich mit dem Benutzernamen „hugo“ und dem Kennwort „hugopass“ an einem Windows-Rechner angemeldet hat, sich bei Lotus Notes erneut und möglicherweise sogar mit einem anderen Benutzerkonto wie „hschmidt“ und „schmidtpass“ anmelden. Diese Situation bringt zahlreiche Nachteile mit sich. In einem SSO-Szenario authentifiziert sich der Benutzer einmal und ausschließlich gegenüber einer einzelnen Domäne. Alle anderen Domänen sind so konfiguriert, dass sie dieser Domäne vertrauen und die für eine Anmeldung notwendigen Informationen von ihr beziehen. Konkrete SSO-Systeme unterscheiden sich in der Art, wie dieses Vertrauensverhältnis aufgebaut wird und wie Authentifizierungsinformationen formatiert und übermittelt werden. Das Ergebnis ist aber immer, dass der Benutzer Anwendungen und Dienste aus anderen Domänen aufrufen kann. Solange das Vertrauensverhältnis besteht, wird der Benutzer als bereits authentifiziert erkannt. Der SSO-Ansatz bietet unterschiedliche Vorteile für eine Organisation:

  • Er beseitigt unnötige und zeitaufwändige Anmeldungen an verschiedenen, unterschiedlichen Domänen (Anwendungen).
  • Er beseitigt das Risiko, dass die Authentifizierung gegenüber einer sekundären Domäne fehlschlägt.
  • Er erhöht die Sicherheit, da Anwender sich nur ein einziges Kennwort merken müssen.
  • Administratoren können einfacher und schneller Benutzer-Accounts verwalten und verbringen weniger Zeit damit Kennwörter zurückzusetzen.
  • Er erhöht die Sicherheit, da Administratoren rasch Benutzerprivilegien über mehrere Systeme ändern können (entweder Hinzufügen oder Entfernen von Privilegien).

Die folgende Abbildung zeigt eine Architektur, die auf ein SSO zurückgreift.

Abb. 2: Single User Sign-On To Multiple Services
Authentication Tokens

Bei den meisten SSO-Implementierungen für Webanwendungen fügt die zentrale Instanz – nach erfolgreicher Authentifizierung – einen Token in den HTTP Header des Browsers ein. Der Browser sendet diesen Token bei jeder Anfrage mit. Wenn eine Anwendung eine solche Anfrage erhält, muss eine Komponente die Anfrage zuerst abfangen und die Gültigkeit beziehungsweise Existenz des Tokens überprüfen. Ist der Token gültig, wird die Anfrage zugelassen. Ist der Token hingegen ungültig, wird der Aufrufer zur zentralen Anmeldeinstanz weitergeleitet. Oftmals wird diese abfangende Komponente „Policy Enforcement Point“ oder kurz PEP genannt. In Java-EE-Anwendungen kann dieser PEP entweder als Java Servlet Filter, als containerspezifische Komponente (z.B. Tomcat Valve) oder anders implementiert werden. Der Token kann entweder in einem proprietären Format oder in einem gebräuchlichen Format wie Kerberos oder SAML (Security Assertion Markup Language) sein. SAML ist ein XML-Dialekt, der ein Standardformat für die Einbettung von sicherheitsrelevanten Informationen wie z. B. Benutzername, Kennwort, Zertifikate und Rollen in XML definiert. Bei SSO-Systemen ist das SAML das Format der Wahl, da die meisten SSO-Systeme dieses Format interpretieren können. Somit lässt sich das SSO-System leichter in die bestehende Systemumgebung integrieren.

Geschrieben von
Bruce Sams
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.