Usability-Überlegungen führen zur Anforderung einfacher Login-Verfahren. Werden mehrere Server verwendet, führt dies zum Einsatz von Single-Sign-On-Techniken. Moderne IT-Landschaften bestehen zunehmend aus heterogenen Systemen. Um in solchen Umgebungen SSO umzusetzen, ist eine zentrale Authentisierungsinstanz und ein Benutzerverzeichnis erforderlich. Im Optimalfall melden sich Benutzer einmalig an dieser zentralen Instanz an und sind danach für alle, zu einer IT-Landschaft gehörenden, Einzelsysteme authentifiziert.

Single-Sign-On mit IBM Domino Directory?

Das IBM Domino Directory stellt allerdings ein wenig geeignetes Verzeichnis für die Anmeldung an solchen Landschaften dar. Häufig kommen heutzutage zentrale Authentisierungssysteme zum Einsatz, die auf die Active-Directory-Technologie von Microsoft oder andere LDAP-Directories setzen. Um das reibungslose Zusammenspiel heterogener IT-Landschaften zu gewährleisten, kommen dabei Technologien wie beispielsweise der Apache Central Authentication Service (CAS) und ein Reverse-Proxy-Server zum Einsatz. Hierbei wird der Reverse-Proxy an das unternehmensinterne Active-Directory angebunden und authentifiziert Benutzer gegen die im MSAD hinterlegten Informationen.

IBM Domino und CAS?

HTTP-Anfragen werden dann von diesem zentralen Server an einzelne Anwendungen auf anderen Systemen weitergeleitet und zuvor um einige zusätzliche Informationen angereichert. Der so angefragte Webserver kann diese Informationen dann nutzen, um die HTTP-Anfrage im Kontext eines Benutzers auszuführen. Ungeachtet der tatsächlichen Komplexität und Heterogenität der zugrundeliegenden IT-Landschaft ergibt sich für den Benutzer hierdurch das Bild eines einzelnen Systems. Lotus Domino verfügt jedoch weder über eine Schnittstelle zur CAS-Technologie noch kann es die zusätzlichen Benutzeridentitäts-Informationen eines Reverse-Proxies verarbeiten. Benutzer, die über einen solchen Unternehmenszugang auf Ihr Domino-Mailfile via iNotes zugreifen wollen, müssen sich daher ein weiteres mal authentifizieren. Eine solche weitere Anmeldung ist für den einzelnen Benutzer nicht nur ärgerlich, sie kann auch leicht zu Fehlern führen. Sind Anmeldename und/oder Passwort unterschiedlich, kann es durch Verwechselung zu entsprechenden Fehleingaben kommen. In der Folge kommt es immer wieder zu Zeitverlust und letztendlich zu einem Aufwand am User Help Desk mit entsprechend messbaren Kosten. Sind Benutzernamen und Passworte identisch, treten in der Regel Akzeptanz-Probleme auf. Die hieraus resultierenden Kosten sind jedoch nur schwer messbar.

Lösung: RPAuth-Erweiterung für den IBM Domino Server

An dieser Stelle setzt die RPAuth-Erweiterung für den IBM Domino Server an. Durch den Einsatz von RPAuth wird die Authentisierung eines Benutzers an eine vertrauenswürdige Instanz ausgelagert. Domino wird in die Lage versetzt, die bei dieser Auslagerung entstehenden Benutzerdatenanreicherungen des Reverse-Proxies zu verarbeiten. HTTP-Anfragen werden so im Kontext eines bereits authentifizierten Domino-Benutzers verarbeitet. Eine wiederholte Anmeldung ist nicht notwendig. Die Benutzeranmeldung erfolgt nur noch einmalig. Administrativer Aufwand des User Help Desks kann nur noch an einer Stelle entstehen und vereinfacht so bereits die Ursachenanalyse.

Funktionsweise

RPAuth

RPAuth setzt auf die Domino Web Server API (DSAPI) auf. Eingehende HTTP(S)Anfragen werden zunächst auf Ihre Herkunft überprüft. Stammt die eingehende Anfrage von einer vertrauenswürdigen Quelle, wird sie auf Benutzerdaten einer bereits erfolgten Authentifizierung überprüft. Sind auch diese Daten in der Anfrage enthalten werden sie für die Identifizierung eines Domino-Benutzers verwendet. Wird im Domino-Directory ein passender Benutzer gefunden, wird die Anfrage in den Kontext dieses Benutzers gesetzt und zur Weiterverarbeitung an den Domino-Server übergeben. Mit der vom Domino-Server gesendeten Antwort wird ein Domino-Sitzungs-Cookie übermittelt. Durch diesen Umstand erfolgen weitere Anfragen bereits von vornherein im Kontext eines angemeldeten Benutzers. Eine erneute Überprüfung derartiger Anfragen durch den RPAuth-Filter ist dann nicht mehr notwendig.

Das Auffinden von Benutzern erfolgt dabei unter Zuhilfenahme der im Domino-Directory verfügbaren Informationen und Einstellungen: Je nach Sicherheitseinstellung des Servers werden entweder alle oder genauer spezifizierte Namenskombinationen verwendet. Auf diese Weise lässt sich RPAuth flexibel an die Sicherheits- und Konfigurationsbedürfnisse eines Unternehmens anpassen. Sollte ein Benutzer dennoch nicht gefunden werden können, wird die gewohnte Domino-Anmeldemaske präsentiert. RPAuth kann daher auch im gemischten Betrieb eingesetzt werden: Zum einen verhalten sich Anfragen, die nicht von einem vertrauenswürdigen Proxy kommen, wie gewohnt. Zum Anderen können Anfragen, die vom Proxy mit unzureichenden Informationen angereichert wurden, ebenso bearbeitet werden, indem die gewohnten Authentifzierungsmechanismen zum Einsatz kommen.

Installation

Die Installation von RPAuth gestaltet sich denkbar einfach in drei Schritten, die in wenigen Minuten durchgeführt werden können. Eine Anpassung des Domino-Directory ist nicht notwendig. Dem Administrator stehen darüber hinaus umfangreiche und flexibel konfigurierbare Log-Informationen zur Verfügung. Hierbei kann die ausgegebene Informationsmenge in mehreren Stufen variiert werden. Die Konfiguration der einzelnen Unterfunktionen ist leicht mithilfe der Domino-Konfigurationsdatei möglich. Damit wird es einem Domino Administrator sehr leicht gemacht, die Funktionsweise des RPAuth-Filters zu überprüfen und zu konfigurieren.

RPAuth ist in C geschrieben. Bei der Entwicklung wurde hoher Wert auf Performanz gelegt. Aus diesem Grund integriert sich RPAuth nahtlos in die Konfigurationsmöglichkeiten des Domino-Servers und es kommt zu keinen messbaren Leistungsverlusten. Zudem ist RPAuth leicht auf die unterschiedlichen Lotus-Domino-Plattformen portierbar. Derzeit existiert RPAuth für Windows 32 und 64 Bit. Versionen für andere Betriebssysteme können auf Anfrage erstellt werden.