Notes/Domino:SSO im Überblick

11.02.2007 von Martin Kuppinger

Nachdem es einige Zeit um das Thema „Single Sign-On“ etwas ruhiger war, ist es in letzter Zeit wieder vermehrt ins Blickfeld gerückt. Die einfachere Nutzung von Anwendungen durch einmalige Authentifizierung und die ausgereifteren technischen Möglichkeiten sind dafür entscheidend. Bei Notes/Domino spielen dabei auch Integrationsaspekte mit dem Workplace eine Rolle.

Single Sign-On bedeutet, dass man mit einer Authentifizierung auf mehr als eine Anwendung zugreifen kann. Das ist in Anbetracht einer ständig wachsenden Zahl an Kennwörtern vor allem für webbasierende Anwendungen und der oft historisch schon sehr hohen Zahl von Kennwörtern von wachsender Bedeutung.

Nun ist das Thema Single Sign-On nicht neu, wie die beachtliche Fülle unterschiedlicher Ansätze zeigt, die es beispielsweise bei Lotus Notes/ Domino gibt. Dennoch ist in diesem Bereich vor allem im vergangenen Jahr einiges an Bewegung entstanden, was unterschiedliche Gründe hat:

Der schon erwähnte steigende Leidensdruck bei Anwendern spielt eine immer wichtigere Rolle. Durch die zunehmende Verknüpfung von Geschäftsprozessen auch über Unternehmensgrenzen hinweg steigt auch die Zahl von Anwendungen, auf die zugegriffen werden muss.
Compliance ist ein zweiter wichtiger Antreiber. Compliance als Begriff bezeichnet die Einhaltung gesetzlicher, aufsichtsbehördlicher und unternehmensinterner Regelungen. Dabei spielen Themen wie das IT-Risikomanagement und damit auch die IT-Sicherheit eine immer größere Rolle. Single-Sign-On-Mechanismen sind eines von vielen Elementen innerhalb von Compliance- Konzepten.
Portale haben sich inzwischen etabliert. Anwendungen, die in Portale integriert werden sollen, sollten auch die Authentifizierungsmechanismen der Portale nutzen. Damit entstehen im Ergebnis Single-Sign-On-Lösungen.
Generell haben sich die technischen Möglichkeiten für die Realisierung von Single-Sign-On- Ansätzen deutlich verbessert. Standards wie 509 und Kerberos, die in solchen Modellen eine wichtige Rolle spielen können, werden auf breiter Basis unterstützt. Aber auch die speziellen Single-Sign-On-Produkte vieler Anbieter haben inzwischen einen hohen Reifegrad erreicht.

Im Ergebnis ist Single Sign-On heute im Vergleich zu früher einfacher umsetzbar. Das Ziel ist aber allenfalls „relativ“, aber nicht „absolut“ einfach zu erreichen. Auch heute müssen verschiedene Bausteine zusammengefügt und relativ komplexe Technologien genutzt werden. Die Chance, das Ziel eines Single Sign-Ons über verschiedene Plattformen hinweg zu erreichen, ist aber viel greifbarer als früher.

Die Entwicklung bei Notes/Domino

Das gilt auch für Lotus Notes/Domino. Dort sind im Laufe der Jahre immer mehr Funktionen hinzugefügt worden, mit denen sich Single-Sign-On- Konzepte umsetzen lassen. Als Lotus Notes 1989 auf den Markt kam, war es schon eine Lösung, die auf den Betrieb mit mehr als einem Server ausgerichtet war. Das Konzept der Zertifikate mit öffentlichen und privaten Schlüsseln gab es schon in der Version 1.0.

Im Laufe der folgenden Versionen wurden viele wichtige Funktionen wie die integrierte Windows- Authentifizierung für den Notes-Client (Client Single Logon Feature) oder die Unterstützung für X.509v3-Zertifikate hinzugefügt. Wichtige Meilensteine in dieser Entwicklung waren:

SSLv3-Unterstützung mit Domino 4.6, wo sich erstmals auch eine CA (Certificate Authority) für die Ausstellung der entsprechenden Zertifikate fand.
Das Release des Domino Directory mit der Version 5.0 und damit in der Konsequenz auch ein LDAP-Server mit Funktionen wie der Directory Assistance und damit der Weiterleitung von Anforderungen.
Die Single-Sign-On-Unterstützung für den Zugriff auf mehrere Domino-Webserver mit dem Release 5.0.3.
Im gleichen Release gab es auch erstmals die Option für ein Single Sign-On mit dem IBM WebSphere Application Server.
Die Integration der CA zwischen Notes- und Internet-IDs mit der Version 6.
Synchronisation von Notes- und Internet-Kennwörtern ab dem Release 6.
Die Verwendbarkeit zentraler Domino Directory-Server ab dem Release 6, so dass man mit dedizierten Servern beispielsweise komplexere Anforderungen an die Authentifizierung externer Benutzer besser erfüllen kann.

Die verschiedenen Ansätze und Komponenten

Wenn man sich die verschiedenen Ansätze und Komponenten bei Notes/Domino betrachtet, die für die Umsetzung von Single-Sign-On-Ansätzen eine Rolle spielen können, kommt man auf eine beachtliche lange Liste:

X.509 kann in Single-Sign-On-Konzepten eine wichtige Rolle spielen, weil sich Benutzer mit einem Zertifikat gegenüber verschiedenen Systemen identifizieren können. Da Lotus Domino die Authentifizierung mit X.509-Zertifikaten unterstützt, lassen sich Webanwendungen, aber auch Mailzugriffe und Remote Java-/DIIOP-Anwendungen über X.509-Client-Zertifikate nutzen. Zudem können solche Zertifikate innerhalb des Intranets auch noch über die Domino-interne CA ausgestellt werden. Da X.509 mittlerweile bei sehr vielen Systemen unterstützt wird, lassen sich darauf basierend auch Single-Sign-On-Lösungen umsetzen.
Domino unterstützt die einmalige Authentifizierung an Webanwendungen, auch wenn diese auf verschiedenen Servern liegen. Die Basis dafür bilden Cookies und die Web SSO Konfigurationsdokumente.
Darauf basiert auch das Zusammenspiel mit IBM WebSphere und anderen Anwendungen von IBM. Die so genannte LTPA (Lightweight Third Party Authentication) ist ein Mechanismus, mit dem Tokens, die als Cookies auf den Clients gespeichert werden, auch über die Grenzen einer Anwendung hinweg eingesetzt werden können. Dieses Verfahren spielt auch bei Portallösungen wie dem IBM Workplace eine zentrale Rolle.
Stattdessen kann aber auch mit externen Lösungen für das Web Single Sign-On gearbeitet werden. Diese auch als EAM (Extranet Access Management) bezeichneten Systeme wie der Netegrity SiteMinder fangen Zugriffe ab, führen die Authentifizierung von Benutzern durch und autorisieren – meist auf Basis von URLs – den Durchgriff auf die webbasierenden Anwendungen. Dabei kann es sich natürlich auch um Domino- Anwendungen handeln.
Eingesetzt werden können aber auch externe SSO-Lösungen auf dem Client. Solche Lösungen speichern lokal oder auf dem Server Credentials Authentifizierungsnachweise) für Anwendungen. Alle wichtigen Anbieter unterstützen auch die Authentifizierung am Lotus Notes-Client.
Lotus selbst bietet mit dem schon erwähnten xClient Single Logon Feature einen einfacheren Mechanismus an, um diese integrierte Authentifizierung durchzuführen. Dabei wird der Windows- Authentifizierung vertraut. Auch die Kennwörter von Windows und der Notes-ID-Datei können synchronisiert werden. Eine vergleichbare Funktionalität gibt es auch beim Macintosh- Client.

Es gibt aber auch Lücken bei den Technologien für Single Sign-On in Lotus Notes/Domino. Die größte Lücke ist derzeit sicherlich die fehlende Unterstützung für Kerberos. Kerberos ist in internen Netzwerken eine interessante Alternative zu X.509. Bei KDCs (Kerberos Key Distribution Centern) können nach der Authentifizierung Tickets für den Zugriff auf weitere Dienste angefordert werden. Diese Dienste müssen die Session Tickets von Kerberos aber akzeptieren, was bei Lotus Domino nicht der Fall ist.

Ebenso fehlt derzeit noch die Unterstützung für Federation-Standards, also SAML, die Liberty Alliance-Standards oder die WS*-Standards. Das dürfte sich aber schon wegen des klaren Commitments von IBM zu Web Services und zur Identity Federation zukünftig ändern, wobei man gespannt sein darf, welche Rolle das Domino Directory in solchen Modellen spielen wird.

Dennoch lassen sich mit den vorhandenen Mechanismen sehr flexibel Lösungen aufbauen, mit denen ein Single Sign-On für Domino-Anwendungen, im Zusammenspiel mit anderen IBM-Anwendungen oder auch mit Lösungen weiterer Anbieter erfolgt. Allerdings wird man sich selten auf nur einen Mechanismus stützen können, sondern verschiedene Verfahren kombinieren müssen, um den Benutzern bei unterschiedlichen Zugriffswegen jeweils Single Sign- On bieten zu können.