Die Popularität von Single-Sign-On-Lösungen (SSO) hat in den letzten Monaten rapide zugenommen. Das hat einen guten Grund: SSO hilft den Benutzern wesentlich zu einer höheren Sicherheit im Unternehmen beizutragen. Denn nichts ist für die Anwender lästiger, als sich eine grosse Zahl von Benutzernamen und Kennwörtern merken zu müssen. Und daraus ergibt sich eine nicht zu unterschätzende Sicherheitslücke: Viele unterschiedliche Benutzernamen/Kennwort-Paare verleiten die Benutzer dazu, ihre Passwörter zu notieren und in unsicherer Weise aufzubewahren. Im schlimmsten Fall werden sie gar per Post-it-Zettel am Monitor befestigt und damit jedem Mitarbeiter zugänglich gemacht.
Single-Sign-On-Lösungen sorgen dafür, dass sich Benutzer nur noch einmal authentifizieren müssen. Damit wird es auch einfacher, mit starken – also komplexeren, aber auch schwieriger zu merkenden – Passwörtern zu arbeiten und gegebenenfalls zusätzlich sogar noch Lösungen für die starke Authentifizierung zu integrieren.
Single-Sign-On ist aber nicht gleich Single-Sign-On. Es lassen sich vielmehr vier gängige Verfahren unterscheiden, wobei es innerhalb dieser Gruppen von Lösungen wiederum deutliche Unterschiede beispielsweise bezüglich der Anwendbarkeit im heterogenen Umfeld gibt. Alle Lösungen haben aber gemein, dass sie die Anzahl der Benutzername/Kennwort-Kombinationen für den Anwender erheblich reduzieren.
Die einfachsten Mechanismen arbeiten dezentral am Client. Dort kennen die meisten Benutzer bereits eine Minimallösung: Wer mit dem Internet Explorer oder anderen gängigen Browsern auf unterschiedliche Websites zugreifen möchte, kann seine Kennwörter speichern. Damit muss er sich nur noch bei Windows authentifizieren, um anschliessend mit dieser einen Anmeldung (Single-Sign-On) weitere Sites nutzen zu können.
Etwas weiter gehen Lösungen mit Tokens oder Smartcards, auf denen die sogenannten Credentials – also die Anmeldeinformationen – gespeichert werden können. USB-Tokens lassen sich am einfachsten nutzen, weil die entsprechende Schnittstelle heute bei allen Systemen zu finden ist, während nicht jeder Rechner über einen Smartcard-Reader verfügt. Solche Lösungen werden von etlichen Herstellern angeboten.
Ein Knackpunkt dabei ist oft die Administration. Solange nicht mit Smartcard-basierenden Lösungen gearbeitet wird, für die auch eine Smartcard-Management-Infrastruktur zur Verfügung steht, lassen sich solche Systeme in vielen Fällen nicht zentral verwalten. Solange es aber keine zentrale Konfiguration im Netzwerk gibt, lässt sich auch kein einheitlich hoher Sicherheitsstandard durchsetzen.
Eine Alternative dazu sind serverbasierende Lösungen, wie sie insbesondere von ActivIdentity und Passlogix angeboten werden. Zu nennen ist darüber hinaus Evidian. Bei diesen Systemen gibt es eine Client-Komponente und einen zentralen Speicher für die Credentials auf einem oder mehreren Servern. Das Konzept hat zwei Vorteile: Zum einen lassen sich die Einstellungen zentral vorgeben. Zum anderen lassen sich auch die Client-Komponenten zentral verwalten, so dass ein stringentes Sicherheitskonzept umgesetzt werden kann. Die Sicherheit hängt bei diesen Verfahren neben der Konfiguration vor allem von der Qualität der zentralen Speicher ab. Wenn Credentials, wie es teilweise möglich ist, im Dateisystem abgelegt werden, ist diese nicht so hoch wie beispielsweise bei der Verwendung des Novell SecretStore – einer besonders sicheren Erweiterung des Novell eDirectories – in Verbindung mit dem auf der ActivIdentity-Technologie basierenden Novell SecureLogin.
Ein ganz anderer Weg wird beim Web Access Management eingeschlagen, das auch als Extranet Access Management bezeichnet wird. Hier übernimmt ein zentrales System als eine Art Proxy die Authentifizierung und erlaubt oder verhindert Zugriffe auf die dahinterliegenden Web-Applikationen. Daher wird die Technologie manchmal auch als Web-Single-Sign-On bezeichnet.
Der Ansatz weist eine wesentliche Einschränkung auf: Eine differenzierte Zugriffssteuerung ist nur bei Eingriffen in die Web-Anwendungen möglich. Die meisten Nutzer haben ihre Anwendungen aber nicht entsprechend angepasst, so dass nur auf dem Level von URLs entschieden werden kann, ob ein Zugriff erfolgen darf oder nicht. Zudem funktioniert das Konzept nur bei Web-Anwendungen.
Web Access Management ist letztlich nur eine Notlösung, um ein höheres Mass an Sicherheit für Web-Applikationen zu schaffen. Diese Art von SSO-Lösung wurde vor allem für bestehende Anwendungen geschaffen, die gegenüber dem Web geöffnet werden sollen. Sie sollten aber kein dauerhafter Ersatz für eine tiefergehende Sicherheitsintegration sein.
Alle bisher beschriebenen Prozeduren sind im Grunde genommen nur Ansätze, die das eigentliche Problem nicht vollständig lösen. Mit diesen Single-Sign-On-Verfahren gibt es faktisch immer noch unterschiedliche Authentifizierungen an den verschiedenen Systemen. Das Problem wird nur entweder durch eine Art Proxy oder durch die Speicherung der Anmeldeinformationen für die dezentralen Systeme in mehr oder weniger sicherer Weise umgangen.
Ansätze wie X.509, Kerberos oder die Identity Federation versuchen hingegen, die Ursachen des Problems zu adressieren. Digitale Zertifikate können ebenso wie Kerberos-Tokens im heterogenen Umfeld eingesetzt werden. Allerdings setzt das immer noch voraus, dass alle Systeme die Benutzer in einheitlicher Weise kennen und eben diese Verfahren unterstützen. Schon die Integration einer Kerberos-Infrastruktur zwischen Windows- und Linux-Systemen ist ein komplexes Unterfangen, ebenso wie der Aufbau einer PKI für die Ausgabe von digitalen Zertifikaten. Und Identity Federation ist ohnehin noch völliges Neuland.
Leider ist es so, dass es keinen Ansatz gibt, der über alle Anwendungen hinweg genutzt werden könnte. Zwar gibt es etliche Systeme, mit denen sich Kerberos oder X.509-Zertifikate nutzen lassen, die Möglichkeiten, eine durchgängige Sicherheitsinfrastruktur zu realisieren, sind jedoch selbst beim Einsatz von Standard-Anwendungen noch sehr begrenzt. Zudem spielt X.509 seine Stärken eher ausserhalb von Unternehmen aus, während firmenintern eher Kerberos der bevorzugte Mechanismus ist. Dennoch muss das Ziel sein, diese Verfahren zu nutzen, um ein wirkliches Single-Sign-On zu realisieren, bei dem Benutzer zentral verwaltet und deren Daten mit Provisioning-Technologien verteilt oder mit Federation-Ansätzen gemeinsam genutzt werden. Neue Anwendungen sollten daher zumindest einen der Standards Kerberos oder X.509v3 unterstützen. Bis man so weit ist, werden aber noch einige Jahre ins Land ziehen. Die weiter oben erwähnten SSO-Verfahren sind eher als Übergangslösung zu sehen. Da sie aber auch mittelfristig noch erforderlich sein werden, selbst wenn ein Unternehmen konsequent auf «echtes» Single- Sign-On via Kerberos, X.509 und Identity Federation setzt, wird man nicht umhin kommen, als Zwischenschritt mit einfacheren Single-Sign-On-Ansätzen zu arbeiten.
Somit stellt sich natürlich auch die Frage, welches Verfahren für wen am besten geeignet ist. Web Access Management stellt dabei ohnehin einen Sonderfall dar. Ansonsten spricht viel dafür, entweder mit einer Smartcard-Infrastruktur und ergänzenden clientbasierenden SSO-Lösungen oder mit serverbasierenden Verfahren – am besten in Verbindung mit zusätzlichen Mechanismen für die starke
Authentifizierung – zu arbeiten.
Der Aufwand für den Aufbau einer Smartcard-Infrastruktur ist dabei allerdings deutlich höher als die Einführung der auf Passlogix- oder ActivIdentity-Technologie basierenden Systeme. Smartcard-basierende Ansätze haben den Vorteil, dass man diese gleichzeitig für eine direkte Authentifizierung an allen Anwendungen auf X.509-Basis einsetzen kann.
Kleinere Unternehmen sind dagegen besser mit einfachen Client-Lösungen bedient, die beispielsweise USB-Tokens nutzen, da der Implementierungsaufwand hier deutlich geringer ist. Aus Gründen der Sicherheit und um den Anwendern den Umgang mit der Authentifizierung zu erleichtern, sollte man aber die Evaluation einer Single-Sign-On-Lösung auf jeden Fall ins Auge fassen. Die verfügbaren Technologien sind heute in der Praxis nutzbar und bringen deutliche Vorteile.
