SSO mit WebSphere/Workplace

Einer der Bereiche, in denen Single Sign-On schon länger eine Rolle spielt, ist die Verbindung von Lotus Domino mit der IBM WebSphere-Plattform. Das gilt noch mehr seit dem Release des IBM Workplace, da dieser auf dem IBM WebSphere Portal Server und damit wiederum auf dem WebSphere Application Server basiert.

Die Integration zwischen IBM WebSphere und Lotus Domino kann über ein spezielles, als LTPA (Lightweight Third Party Authentication) bezeichnetes Token erfolgen, das bei den Clients als Cookie gespeichert wird.

Um diesen Mechanismus zu nutzen, sind Konfigurationsschritte sowohl bei WebSphere als auch bei Lotus Domino erforderlich.

Das LTPA-Token

Das LTPA-Token wurde mit der Version 3.0 von IBM WebSphere eingeführt und wird seit der Version 5.0.3 auch bei Lotus Domino unterstützt, ebenso wie es beispielsweise auch bei Sametime und anderen Anwendungen zu finden ist.

Vom Konzept her wird bei dem LTPA-Token mit einer Vertrauensstellung zwischen verschiedenen Systemen gearbeitet, auch wenn das von IBM nicht explizit so bearbeitet wird. Ein System erzeugt das Token, das von anderen Systemen ebenfalls akzeptiert wird.

Sowohl Lotus Domino als auch der WebSphere Application Server (WAS) verfügen über einen LTPA-Dienst, der mit den LTPA-Tokens arbeiten kann (Bild 1). Dieser Dienst kann solche Tokens erzeugen und sie konsumieren, wenn ein Benutzer zugreift. In beiden Fällen ist ein Zusammenspiel mit einem Verzeichnisdienst erforderlich. Das kann das Domino Directory sein, aber auch ein anderer LDAP-Verzeichnisdienst.

Je nach verwendetem Verzeichnisdienst gibt es im Zusammenspiel zwischen den unterschiedlichen Plattformen spezielle Herausforderungen beispielsweise für das User Name Mapping, also die Abbildung unterschiedlicher Benutzernamen wie Martin Kuppinger/Kuppinger und cn=Martin Kuppinger,ou=beratung,o= kuppinger aufeinander. Darauf wird weiter unten noch näher eingegangen.

Aus Sicht von Lotus Domino wird immer mit dem Domino Directory gearbeitet, wobei über die Directory Assistance Database auch eine Weiterleitung der Anforderungen zu anderen LDAP Verzeichnissen erfolgen kann. Der WAS kann dagegen so konfiguriert werden, dass er direkt mit dem Domino Directory als Verzeichnisdienst arbeitet.

Das erzeugte LTPA-Token wird auf dem Client in einem Cookie gespeichert. Damit diese Form der Kommunikation sicher ist, werden die darin enthaltenen Informationen verschlüsselt. Die Verschlüsselung erfolgt über einen Schlüssel, der auf dem WAS erzeugt und von diesem exportiert wird. Der Schlüssel kann anschließend auf anderen Systemen wie dem Domino Server wieder importiert werden. Der Schlüssel ist mit einem Kennwort gesichert. Da dieses Kennwort erhebliche Bedeutung für die Gesamtsicherheit von LTPA hat, sollte es ausreichend stark gewählt und nur für diesen Zweck eingesetzt werden. Das LTPA-Token selbst enthält folgende Informationen:

• Benutzerdaten, also in der Regel die Benutzer- ID. Es kann sich aber prinzipiell um jede Information handeln, die dazu geeignet ist, den Benutzer eindeutig zu identifizieren.

• Ablaufzeit für den Token. In der Regel wird inzwischen mit einem Zeitraum von 120 Minuten gearbeitet, der aber konfigurierbar ist. Ältere Versionen haben ein Intervall von nur 30 Minuten verwendet. Der Zeitraum sollte nicht zu lang gewählt werden, da die Missbrauchsgefahr mit längerer Gültigkeitsdauer steigt.

• Digitale Signatur zur Validierung des Tokens. Diese Information wird auf Basis des Schlüssels erzeugt.

Das gesamte LTPA-Token ist verschlüsselt und wird in ein Cookie eingebunden. Das Cookie enthält wiederum die folgenden Informationen:

• Den Namen des Cookies, der immer auf Ltpa- Token gesetzt wird.

• Die Domäne. Damit ein Cookie von mehreren Systemen genutzt werden kann, müssen diese zu einer Internet-Domäne gehören. Diese Domäne muss im Cookie gesetzt werden.

• Ablaufdatum des Cookies. Dieses Ablaufdatum ist ein anderer Wert als die oben genannte Lebensdauer des LTPA-Tokens. Damit wird gesteuert, wie lange das Cookie auf dem Browser gespeichert wird. Die Einstellung ist in diesem Fall so, dass das Cookie mit dem Ende einer Browser-Sitzung gelöscht wird.

• Sicherheit: Dieser Wert kann auf on gesetzt werden, damit die LTPA-Cookies nur über SSL gesendet werden dürfen. Bevor eine solche Konfigurationsoption gewählt wird, muss aber geprüft werden, ob die Arbeitsumgebung auch diese Voraussetzungen erfüllt.

• Cookie-Wert: Hier findet sich das LTPA-Token selbst, das aus Sicht des Cookies eine verschlüs- selte Zeichenkette ist.

Das Konzept von LTPA ist im Prinzip recht einfach und hat den Vorteil, dass keine komplexere Infrastruktur beispielsweise mit digitalen Zertifikaten nach dem X.509-Standard aufgebaut werden muss. Soweit Systeme LTPA unterstützen, ist damit ein relativ einfacher Single Sign-On über verschiedene Systeme hinweg realisierbar.

Die Konfiguration bei WebSphere

LTPA muss auf allen beteiligten Systemen konfiguriert werden. Da der IBM Workplace auf dem WAS basiert und die Administrationskonsole des IBM Workplace nichts anderes als eine erweiterte Variante der normalen Verwaltungsschnittstelle des WAS ist, findet sich dort auch die Schnittstelle für die LTPA-Konfiguration. Bei Sicherheit/ Authentifizierungsverfahren/LTPA können die entsprechenden Einstellungen vorgenommen werden.

In diesem Bereich stehen vier Optionen zur Verfügung (Bild 2). Bei Kennwort wird das gemeinsame Kennwort festgelegt, das für den Export und Import des Schlüssels verwendet wird. Dieses Kennwort muss bei Kennwort bestätigen noch einmal eingetragen werden. Sie sollten das Kennwort auf einen neuen, komplexen und von Ihnen festgelegten Wert setzen, bevor Sie erstmals LTPA-Schlüssel erzeugen und exportieren.

Darunter findet sich das Zeitlimit. Es legt die Lebensdauer des LTPA-Tokens fest und steht, wie oben schon erwähnt, standardmäßig auf 120 Minuten. Der Wert kann angepasst werden, wobei die 120 Minuten in den meisten Einsatzbereichen eine sinnvolle Größe sind.

Schließlich müssen Sie noch den Namen der Schlüsseldatei angeben, die für LTPA genutzt werden soll. Diese Datei müssen Sie nach der Erstellung des Schlüssels auf die anderen Systeme mit LTPA-Unterstützung exportieren.

Über den Optionen finden sich drei Schaltflächen:

• Schlüssel generieren erzeugt einen neuen LTPA-Schlüssel. Diesen Befehl müssen Sie nach der Anpassung von LTPA-Einstellungen ausführen.

• Schlüssel importieren lädt einen LTPA-Schlüssel von einem anderen System.

• Schlüssel exportieren speichert den LTPASchlüssel in der angegebenen Datei.

Änderungen in diesem Bereich werden erst gespeichert, wenn Sie im Bereich Sicherheit/Globale Sicherheit die Änderungen übernommen haben, indem Sie die Schaltfläche Anwenden oder OK auswählen. Auf diesen Bereich wird weiter unten noch näher eingegangen.

Unterhalb der Optionen finden sich Links zu zwei weiteren Konfigurationsbereichen. Bei Trust Association können Sie die Verbindung mit Reverse- Proxy-Servern als Authentifizierungsserver konfigurieren. Diese Einstellung ist für das Zusammenspiel zwischen WebSphere und Domino nicht relevant.

Der zweite Bereich ist Single Sign-On (SSO). Hier können Sie weitere wichtige Festlegungen für die LTPA-Tokens vornehmen (Bild 3):

• Aktiviert legt fest, dass mit einem Single Sign- On über LTPA gearbeitet werden kann. Diese Option muss gesetzt sein, um mit dem Verfahren arbeiten zu können.

• Erfordert SSL sorgt dafür, dass zwingend mit SSL gearbeitet werden muss, soweit LTPA genutzt werden soll. Das ist aus Sicherheitsgründen zwar empfehlenswert, kann den Einsatz der Technologie aber deutlich einschränken.

• Domänenname gibt den Name der Domäne an, für die mit dem LTPA-basierenden SSO gearbeitet werden soll. Diese Einstellung ist wichtig, damit mehrere Hosts auf das Cookie zugreifen können. Falls hier ein Hostname statt nur des Domänennamens eingetragen wird, können nur Anwendungen auf diesem Rechner mit LTPA arbeiten.

Weitere Konfigurationseinstellungen für LTPA finden sich im Bereich Sicherheit/Globale Sicherheit. Dort können Sie das Authentifizierungsverfahren für den WAS konfigurieren und damit die Nutzung von LTPA überhaupt erst aktivieren – ein konfiguriertes Token alleine bedeutet noch nicht, dass mit LTPA gearbeitet wird.

In diesem Bereich kann bei Aktives Authentifizierungsverfahren konfiguriert werden, ob mit LTPA oder mit SWAM (Simple WebSphere Authentication Mechanism) gearbeitet wird. SWAM ist das Standardverfahren, das keine Interoperabilität mit anderen Plattformen bietet.

Darunter findet sich die Option Aktive Benutzer- Registry. Sie steuert, auf welches Verzeichnis zugegriffen wird. Darauf wird im Zusammenhang mit der Anpassung des von WebSphere verwendeten Verzeichnisdienstes weiter unten diesem Artikel noch näher eingegangen.

Das LTPA User Name Mapping

Eine der Herausforderungen bei der Verwendung von LTPA besteht darin, dass in dem Token ein Benutzername gespeichert wird, der in allen Systemen erkannt werden muss. Da WebSphere und Domino aber mit einer unterschiedlichen Notation für solche Namen arbeiten, ist das problematisch. Daher mussten bisher LTPA-Tokens auch bei WebSphere erzeugt werden. Außerdem war ein gemeinsames Verzeichnis er forderlich.

Mit dem LTPA User Name Mapping kann das nun umgangen werden. Dazu wird ein Mapping für den Benutzernamen definiert. Falls die Notes-Benutzerinformationen nur im Domino Directory liegen, wird das Mapping im Personendokument definiert. Bei Zugriffen auf ein externes LDAP-Verzeichnis über die Directory Assistance erfolgt die Anpassung bei der Directory Assistance. Falls beide Verzeichnisse verwendet werden, müssen die Modifikationen auch an zwei Stellen durchgeführt werden.

Dabei ist es auch möglich, mit einem anderen Attribut zu arbeiten. Bei der Directory Assistance kann das Attribut explizit konfiguriert werden.

Die Konfiguration bei Domino

Nach dem Export des Schlüssels für das LTPA-Token kann die Konfiguration bei Lotus Domino durchgeführt werden. Sie erfolgt über die Schnittstellen für die Web-SSO-Konfiguration. Damit befasst sich der folgende Artikel noch näher, so dass wir uns hier auf die spezifischen Aspekte für die Nutzung von LTPA mit WebSphere beschränken.

Sie können bei Configuration im Bereich Web/Internet Sites mit Create Web SSO Configuration ein neues Konfigurationsdokument für das Web Single Sign-On erstellen bzw. ein vorhandenes Dokument modifizieren (Bild 5). In ein solches Dokument können Sie über die Schaltfläche Keys/Import WebSphere LTPA Keys den oder die LTPA-Schlüssel von WebSphere importieren. Dazu müssen Sie den Pfad und das Passwort dafür angeben.

In dem Dokument lässt sich ab Domino 7 auch das Name Mapping für LTPA aktivieren. Wenn Sie diese Option aktiviert haben, können

Sie im Personendokument weitere Festlegungen vornehmen. Das Personendokument enthält im Register Administration das Feld LTPA user name (Bild 6). Dort kann der Benutzername angegeben werden, der für LTPA verwendet werden soll. Hier muss ein Name in LDAP-Notation angegeben werden, also beispielsweise

cn=Martin Kuppinger,ou=Beratung,o=Kuppinger

Dieser Name muss sich im anderen Verzeichnis finden.

Die Verwendung des LTPA User Name Mapping ist allerdings keine optimale Lösung, weil das Problem dabei ist, dass man mit getrennten Verzeichnissen arbeitet und auf andere Weise sicherstellen muss, dass die Informationen darin synchron sind – dass also ein Benutzer genauso im Domino Directory wie im anderen verwendeten Verzeichnisdienst angelegt wird. Das kann zwar mit Provisioning-Lösungen erreicht werden, es macht aber insgesamt mehr Sinn, mit einem Verzeichnisdienst sowohl für Domino als auch den WAS sowie gegebenenfalls weiteren Systemen zu arbeiten, die LTPA verwenden.

LDAP-Integration

In engem Zusammenhang mit der Konfiguration von LTPA ist daher die LDAP-Konfiguration beim WAS bzw. beim IBM Workplace zu sehen. In der Regel wird ein zentraler Verzeichnisdienst zum Einsatz kommen, auch wenn die Architektur von LTPA (Bild 1) und die Konfigurationsoptionen beispielsweise für das User Name Mapping, auf die im vorangegangenen Abschnitt eingegangen wurde, auch andere Optionen zulassen.

Die Konfiguration des LDAP-Servers erfolgt in der Administrationskonsole des WAS über sicherheit/Benutzer-Registrys/ LDAP. Die dort vorgenommen Anpassungen müssen abschließend über Sicherheit/Globale Sicherheit und dort die Festlegung von LDAP als Aktive Benutzer-Registry aktiviert werden.

Im Bereich LDAP können Sie zunächst die Authentifizierungseinstellungen für den LDAP-Server festlegen. Hier müssen Sie den Benutzernamen und das Kennwort eintragen. Diese Informationen werden für die Anforderung von Basisdaten benötigt und müssen administrative Zugriffe erlauben. Es gibt zusätzlich die Option, einen Bindungsnamen festzulegen, der für die laufenden Zugriffe auf den LDAP-Server verwendet wird.

Danach folgt die Auswahl des Servertyps. Um auf ein Domino Directory zuzugreifen, müssen Sie an dieser Stelle Domino auswählen. Der LDAP-Dienst muss beim Domino Directory aktiviert sein.

Die nächste Option ist Host. Hier wird der Hostname des Systems angegeben. Außerdem können Sie bei Port noch den Port festlegen, auf den zugegriffen wird. In der Regel wird unverschlüsselt über Port 389 gearbeitet. In diesem Zusammenhang sind auch die Optionen SSL aktiviert und SSL-Konfiguration weiter unten in dem Eingabedialog von Bedeutung. Mit diesen kann SSL aktiviert werden, was die Änderung des Ports auf den Wert 636 bedingt. Dazu muss bei SSLKonfiguration eine für den WAS vorab definierte Konfiguration ausgewählt werden, in der beispielsweise die Zertifikate festgelegt sind.

Die Option Definierter Basisname (DN) legt fest, wo im LDAP-Baum die Bindung erfolgt. In komplexeren LDAP-Strukturen kann damit der Bereich, auf den über den WAS zugegriffen wird, eingeschränkt werden. Hier muss ein DN (Distinguished Name) beispielsweise in der Form ou=beratung,o=kuppinger angegeben werden.

Darunter kann der bereits weiter oben erwähnte Bindungsname samt dem zugehörigen Kennwort definiert werden. Diese Informationen sind optional und werden für die laufenden Zugriffe verwendet. Sie müssen eingegeben werden, wenn eine Authentifizierung erforderlich ist und wenn nicht mit dem gleichen Konto wie beim Zugriff auf die Basisinformationen gearbeitet werden soll.

Das Suchzeitlimit legt die maximale Dauer für eine Abfrage fest. Dieser Wert ist mit 120 Sekunden bereits relativ hoch gewählt und kann mit anderen Timeouts kollidieren. Wenn Abfragen vom LDAP-Server nicht in diesem Zeitraum beantwortet werden können, schlägt die Authentifizierung fehl. Die Infrastruktur sollte aber darauf ausgelegt sein, innerhalb weniger Sekunden eine Antwort zu liefern, so dass normalerweise auch ein kürzerer Zeitraum in Frage kommt.

Mit der Option Verbindung wieder verwenden, die standardmäßig aktiviert ist, wird erreicht, dass weitere Abfragen innerhalb einer bestehenden Verbindung erfolgen. Damit wird der relativ zeitaufwändige Neuaufbau von Verbindungen vermieden. Es gibt kaum Situationen, in denen diese Option verändert werden muss.

Außerdem kann die Groß-/Kleinschreibung bei LDAP-Zugriffen ignoriert werden. IBM empfiehlt, diese Option im Zusammenspiel mit Domino zu aktivieren.

Wie fast immer gibt es auch noch erweiterte Einstellungen, die sich unterhalb der Optionen finden. Mit Erweiterte LDAP-Einstellungen können Sie weitere Parameter für den Zugriff auf den LDAP-Server festlegen.

Dabei handelt es sich in erster Linie um LDAPFilter. Mit dem Benutzerfilter wird angegeben, wie nach Benutzern gesucht wird. Hier ist gegebenenfalls die Anpassung der Objektklasse erforderlich. Standardmäßig wird über die Objektklasse inetOrgPerson gearbeitet, die aber nicht bei jedem LDAP-Verzeichnisdienst implementiert ist. Hier könnte beispielsweise eine Anpassung auf user erforderlich sein. Gleiches gilt auch für Gruppen, wo nicht unbedingt mit groupOf- Names gearbeitet wird, sondern teilweise auch group oder eine andere Objektklasse zum Einsatz kommt. Analog dazu können und müssen gegebenenfalls auch die Einstellungen darunter angepasst werden. Dabei geht es um die Zuordnung unterschiedlicher Attribute für Benutzer und Gruppen. Diese Optionen beinhalten jeweils
ein oder mehrere Wertepaare der Form Objektklasse: Attributtyp. Statt inetOrgPerson:uid könnte beispielsweise user:cn erforderlich sein, um die Benutzer-ID in einem Verzeichnis zu ermitteln, wenn mit einer anderen Objektklasse und einem anderen Attributtyp gearbeitet wird.

Außerdem können noch Festlegungen für die Zertifikatzuordnung getroffen werden. Die Zuordnung von Zertifikaten kann entweder auf einer exakten Übereinstimmung des DNs in Zertifikat und Verzeichnis erfolgen oder durch einen bei Zertifikatfilter angegebenen Filter angepasst werden. Ein solcher Filter ist erforderlich, wenn die Namen im Verzeichnis nicht exakt mit den Informationen im Zertifikat übereinstimmen, um das richtige Mapping zu ermöglichen.

Neben den erweiterten LDAP-Einstellungen gibt es noch den Bereich Benutzerdefinierte Merkmale. Dort können Sie weitere Attribute konfigurieren, auf die zugegriffen werden soll.

Die vielen Konfigurationseinstellungen machen deutlich, dass der Weg zur Verwendung von LTPA relativ lang ist. Er ist aber nicht besonders komplex. Unter Umständen kann es auch erforderlich sein, zusätzlich die Directory Assistance bei Lotus Domino zu konfigurieren, um Anforderungen an den Domino-Server an einen anderen LDAP-Server weiterzuleiten, der vom IBM WebSphere Application Server verwendet wird, oder um mehrere Domino Directories zu verknüpfen. Auch dort gibt es, wie weiter oben ausgeführt, eine spezielle LTPA-Unterstützung in Form des User Name Mapping.

LTPA ist als Mechanismus aber in jedem Fall so interessant, dass das Verfahren näher evaluiert werden sollte, wenn der WAS, der IBM Workplace, Lotus Domino und andere Anwendungen mit LTPA-Unterstützung parallel zum Einsatz kommen. Mit LTPA können Single-Sign-On-Lösungen zumindest für diese Anwendungen realisiert werden, was dem Benutzer die Arbeit deutlich vereinfacht.