Single Sign-On – Eine Einführung

Viele Benutzer verwenden täglich eine Menge unterschiedlicher Systeme. Bei jedem dieser Systeme müssen sich die Benutzer separat anmelden, im Optimalfall mit unterschiedlichen Passwörtern. Daher muss man sich als User eine große Menge an Zugangsdaten für all diese Systeme merken. Dies führt dann bei der Mehrzahl der Nutzer dazu, dass sie ständig eines der Passwörter vergessen. Als Resultat wird der Workload am Service Desk durch all die “Passwort-vergessen”-Anfragen signifikant erhöht. Wer sich die vielen verschiedenen Passwörter nicht merken möchte, verwendet überall ein ähnliches oder sogar das gleiche Passwort. Darunter leidet dann die allgemeine Sicherheit der Benutzerkonten.

Eine viel bessere Alternative bietet hier Single Sign-On (SSO). Dabei muss ein Nutzer sich im Optimalfall nur noch einmal anmelden und kann dann auf alle seine Systeme und Services zugreifen.

In diesem Artikel soll eine Einführung in die Konzepte hinter Single Sign-On gegeben werden. Nach einer allgemeinen Einführung folgt eine kurze Diskussion der Vor-und Nachteile, sowie eine Zusammenfassung der wichtigsten konzeptionellen Ansätze. Dazu treten wir zunächst einmal einen Schritt zurück und betrachten das Authentifizierungsproblem etwas abstrakter. Worum geht es bei der Authentifizierung eigentlich?

Identitäten und Vor-/Nachteile von SSO

Im Prinzip hat jeder Mensch ja eine physische Identität. Im Internet wird diese dann über mehrere logische Identitäten abgebildet, welche dann auf die Services gemappt werden. Dies ist in der folgenden Abbildung visualisiert:

SSO: Physische und Logische Identitäten

SSO: Physische und Logische Identitäten


Die Physische Identität von Max Mustermann lässt sich beispielsweise auf seine logischen Identitäten auf Facebook, Twitter und LinkedIn übertragen. Hierbei muss jeder Anbieter (Facebook, Twitter, etc.) eine logische Identität von Max Mustermann redundant aufbewahren, um diesen dann bei der Verwendung des Dienstes identifizieren zu können.

Abstrakt betrachtet geschieht das Mapping von der Physischen Identität Max Mustermanns auf seine logischen Identitäten (sein Twitter Account, etc.) über einen Authentifizierungsprozess. Dieser kann beispielsweise die Eingabe einer Emailadresse und eines Passwortes beinhalten. Durch diese Kombination kann der Benutzer dann eindeutig identifiziert werden und seiner logischen Identität zugeordnet werden. Diesen Authentifizierungsprozess für jeden einzelnen Dienst durchzuführen, ist zeitaufwändig, möglicherweise unsicher und unterscheidet sich von Dienst zu Dienst.

Für dieses Problem gibt es das Konzept des Single Sign-On. Einmal anmelden, auf alles zugreifen. Das hat einige Vorteile. So kann beispielsweise Zeit beim Login-Prozess gespart werden, da dieser für jeden Dienst redundante Prozess wegfällt. Auch ist in der Theorie die allgemeine Sicherheit höher, da Identifizierungsdetails, wie etwa ein Passwort, nur einmal abgefragt und übertragen wird. Außerdem ist die Stelle, an der die Authentifizierung stattfindet, bekannt und kann besonders abgesichert werden. Wenn doch mal eine Identität entwendet oder von einem unauthorisierten Benutzer verwendet wird, müssen die Authentifizierungsdetails nur an einer zentralen Stelle einmalig geändert werden, um alle Dienste für den betroffenen Nutzer wieder sicher zu machen. Der Nutzer muss dann nicht etwa an zwanzig Stellen sein Passwort ändern.

Dies kann allerdings gleichzeitig auch zu einem Nachteil werden. Wenn eine Identität einmal gestohlen ist, kann der Angreifer direkt auf sämtliche verbundene Services zugreifen und damit weitaus mehr Schaden anrichten, als wenn nur ein isolierter Dienst kompromittiert wurde. Auch kann es, je nach Implementierung des SSO, zu einem Single-Point-of-Failure im System kommen. Somit ließe sich beim Ausfall des hochkritischen Authentifizierungssystems plötzlich keiner der Services mehr verwenden.

Dies kann außerdem relevant werden, sobald SSO-Lösungen auf externe Server angewiesen sind, etwa bei einem Social-Login via Google-Account oder Facebook-Account, so müssen diese Server vom lokalen Netz aus auch verfügbar sein. Dies kann zu Problemen führen, wenn etwa ein Land die Google-Server blockiert oder an einer Schule die Facebook-Nutzung technisch unterbunden wurde. Hier könnten derartige SSO-Dienste dann nicht mehr verwendet werden.

Insbesondere in Bezug auf den Social-Login mit Facebook drängt sich aus aktuellem Anlass auch gleich die Frage nach dem Datenschutz auf. Dieser kann natürlich zu einem Problem werden, da der Identity-Provider oder SSO-Server je nach Implementierung mitbekommt, welche Services ein User wann nutzt. Diese Daten könnten natürlich zweckentfremdet und etwa zu Werbezwecken eingesetzt werden.

All diese Vor- und Nachteile sind abhängig vom unterliegenden Ansatz und den verwendeten Technologien unterschiedlich stark ausgeprägt.

Unterschiedliche Ansätze

Da es sich bei Single Sign-On eher um ein allgemeines Konzept handelt, gibt es einige unterschiedliche Ansätze zur Implementierung. Im Folgenden werden einige relevante Ansätze kurz erläutert. Konkrete Implementierungstechnologien, wie etwa SAML oder OAuth2 werden in einem folgenden Artikel besprochen. Hier soll es erst einmal um die grundlegenden Konzepte gehen.

Medienlösung

Bei der Medienlösung wird zur Authentifizierung ein elektronisches Token verwendet. Dies kann beispielsweise ein RSA SecurId Hardware Token sein, welches einen Code auf einem Display anzeigt, der dann im System eingegeben wird. Alternativ kann es einen Hardwareschlüssel geben, etwa als dediziertes Gerät, welches beispielsweise über USB oder Bluetooth mit dem Computer verbunden wird. Außerdem gibt es inzwischen einige Smartphone-Apps, welche die gleiche Funktionalität beinhalten und einem das zusätzliche Gerät ersparen.

Portalbasierte Lösung

SSO: Portalbasierte Lösung

SSO: Portalbasierte Lösung

Wie in dieser Abbildung zu erkennen ist, wird beim portalbasierten Ansatz ein SSO-Server als Portal den einzelnen Services vorgeschaltet. In unserem Beispiel authentifiziert sich der Benutzer also beim SSO-Server. Die nachgeschalteten Services vertrauen dem SSO-Server. So kann der SSO-Server beispielsweise ein Session-Cookie oder ein Token an den Client zurückgeben oder ihm ein Zertifikat ausstellen. Mit diesem Cookie/Token/Zertifikat kann sich der User dann bei den einzelnen Services direkt einloggen. Alternativ kann ein Ticket ausgestellt werden, welches dann von den Diensten über den SSO-Server geprüft werden kann.

Ein klassisches Beispiel für ein stark integriertes portalbasiertes SSO ist Microsoft Passport. Ein recht weit verbreitetes Authentifizierungssystem basierend auf dem Ticket-System ist Kerberos.

Circle of Trust

Beim Circle of Trust gibt es ein Netzwerk aus vertrauenswürdigen Diensten, die sich gegenseitig vertrauen. Hierbei gibt es keinen zentralen SSO-Server, vielmehr kann jedes System als SSO-Server auftreten. Dies ist in der folgenden Abbildung visualisiert:

SSO: Circle of Trust

SSO: Circle of Trust

Sobald sich ein Benutzer bei einem der Systeme im “Circle of Trust” authentifiziert hat, erhält er ein Ticket von diesem System. Dieses Ticket kann dann zur Authentifizierung an allen anderen Systemen innerhalb des “Circle of Trust” verwendet werden. Die anderen Systeme “glauben” also, dass das System, welches das Ticket ausgestellt hat, die Identität des Benutzers korrekt festgestellt hat. Im obigen Beispiel authentifiziert sich der Benutzer beim “Atlassian Jira”-Service und erhält ein Ticket. Mit diesem Ticket kann er sich dann beim “Atlassian Bitbucket”-Service anmelden.

Ein Beispiel hierfür ist das Liberty Alliance Project.

Lokale Lösung

Die lokale Lösung ist momentan besonders weit verbreitet, da hierbei keine zusätzlichen Server seitens des Anbieters benötigt werden. Bei diesem Ansatz wird die Authentifizierung direkt beim Client in einer lokal installierten Anwendung abgehandelt. Diese Anwendung trägt dann automatisch die korrekten Daten für den Benutzer in die Felder ein. Ein Beispiel hierfür sind Passwort-Manager Produkte.

SSO: Passwort Manager

SSO: Passwort Manager

Wie in der Abbildung oben zu sehen ist, greift der Benutzer zunächst auf seinen lokal installierten Passwort-Manager zu. Dieser verwahrt alle Zungangsdaten für den Benutzer, meist geschützt durch etwa ein Master-Passwort. Der Passwort-Manager meldet den Benutzer dann direkt bei dem ausgewählten System an. Natürlich kann der Passwort-Manager auch in Kombination mit einem SSO-Server verwendet werden und sich für den Benutzer dort anmelden.

Short URL for this post: https://wp.me/p4nxik-37f
This entry was posted in Did you know? and tagged , , , . Bookmark the permalink.

Leave a Reply