Sie können eine eigene SSO-Tokenimplementierung erstellen. Die SSO-Tokenimplementierung
wird im Anmeldesubjekt definiert und der HTTP-Antwort als HTTP-Cookie hinzugefügt.
Informationen zu diesem Vorgang
Der Cookie-Name ist eine Verknüpfung aus der API SingleSignonToken.getName
und der API SingleSignonToken.getVersion. Es wird kein Begrenzer verwendet. Wenn Sie dem Subjekt ein SSO-Token
hinzufügen, wird an Einheiten derselben Ebene und an untergeordnete Einheiten weitergegeben, sofern das Subjekt
für weitere Webanforderungen verwendet wird. Wenn Sie Ihr angepasstes SSO-Token
von einer weitergegebenen Anmeldung empfangen, müssen Sie es entserialisieren. Falls Sie eine der folgenden Tasks ausführen möchten, sollten Sie das Schreiben einer eigenen Implementierung
in Erwägung ziehen:
- Eingrenzen Ihrer Attribute auf Ihre eigene Implementierung
- Angepasste Serialisierung der Informationen. Verschlüsseln Sie die Informationen, da sie in der HTTP-Antwort enthalten
und damit im
Internet verfügbar sind. Sie müssen die Bytes am Ziel entserialisieren oder entschlüsseln und diese Informationen
wieder zum Subjekt hinzufügen.
- Sicherstellen der Eindeutigkeit des Subjekts mit der API getUniqueID.
Führen Sie die folgenden Schritte aus, um ein angepasstes SSO-Token zu implementieren:
- Schreiben Sie eine angepasste Implementierung der Schnittstelle "SingleSignonToken".
Es gibt
viele verschiedene Möglichkeiten, die Schnittstelle "SingleSignonToken" zu implementieren. Stellen Sie in jedem Fall
sicher, dass die für die Schnittstelle "SingleSignonToken" und die Tokenschnittstelle erforderlichen
Methoden vollständig implementiert sind.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Stellen Sie diese Schnittstelle nach der Implementierung
in das Verzeichnis Stammverzeichnis_des_Anwendungsservers/classes.
Alternativ können Sie die Klasse in jedes private Verzeichnis stellen. Vergewissern Sie sich jedoch,
dass das Klassenladeprogramm von WebSphere Application Server die Klasse finden kann und die entsprechenden Berechtigungen
hat. Sie können die JAR-Datei oder das Verzeichnis mit dieser Klasse in die
Datei server.policy aufnehmen, damit die Klasse die für den Server-Code erforderlichen Berechtigungen
hat.
Stellen Sie die Klasse dieser Schnittstelle nach der Implementierung
in das Verzeichnis Stammverzeichnis_des_Anwendungsservers/classes.
Weitere Informationen zu Klassen finden Sie im Artikel Unterverzeichnis "classes" im Profil für angepasste Klassen erstellen.
Tipp: Alle vom Framework für Weitergabe definierten Tokentypen haben ähnliche Schnittstellen. Im Wesentlichen sind die Tokentypen
Markierungsschnittstellen, die die Schnittstelle "com.ibm.wsspi.security.token.Token"
implementieren. Diese Schnittstelle definiert die meisten Methoden. Falls Sie mehrere Tokentypen implementieren möchten, sollten
Sie eine abstrakte Klasse erstellen, die die Schnittstelle
"com.ibm.wsspi.security.token.Token" implementiert. Alle Ihre Tokenimplementierungen, einschließlich der Implementierung des
SSO-Token, können die abstrakte Klasse erweitern, sodass kaum weitere Schritte erforderlich sind.
Ein Beispiel für die
Implementierung des SSO-Token finden Sie im Artikel Beispiel: Implementierung von com.ibm.wsspi.security.token.SingleSignonToken.
- Fügen Sie das angepasste SSO-Token während der WebSphere Application Server-Anmeldungen hinzu und rufen Sie es ab. Zu diesem Zweck wird in der Regel ein angepasstes Anmeldemodul zu den verschiedenen
Anmeldekonfigurationen für Anwendungen und Systeme hinzugefügt. Zum Entserialisieren der Informationen müssen Sie ein angepasstes Anmeldemodul
anbinden. Dieser Schritt ist in einem der folgenden Abschnitte
beschrieben. Nachdem im Anmeldemodul eine Instanz des Objekts erstellt wurde, können Sie das Objekt während der Methode
"commit" zum Subjekt hinzufügen.
Das Codebeispiel im Artikel
Beispiel: Angepasstes Anmeldemodul mit SSO-Token zeigt, wie Sie feststellen können, ob es sich bei der Anmeldung um eine
Erstanmeldung oder eine weitergegebene Anmeldung handelt. Diese Anmeldetypen unterscheiden sich durch das Vorhandensein bzw. Nichtvorhandensein
von Weitergabedaten im Callback WSTokenHolderCallback. Enthält der Callback keine Weitergabedaten, initialisieren Sie eine neue angepasste
SSO-Tokenimplementierung, und definieren Sie sie im Subjekt. Falls das HTTP-Anforderungsobjekt im Callback verfügbar ist,
suchen Sie auch nach dem HTTP-Cookie
der HTTP-Anforderung.
Ihr angepasstes SSO-Token können Sie über eine weitergegebene Anmeldung auf derselben Ebene und
aus der HTTP-Anforderung abrufen. Es wird jedoch empfohlen, das Token an beiden Stellen verfügbar zu machen, da die Informationen
dann bei allen Front-End-Anwendungsservern ankommen, selbst wenn diese Server keine Weitergabe unterstützen.
In der Festschreibungsphase des Anmeldemoduls
können Sie für Ihr SSO-Token den Schreibschutz festlegen. Ist das Token schreibgeschützt, können in Ihren Anwendungen keine Attribute
hinzugefügt werden.
Einschränkung: - Für HTTP-Cookies gibt es eine maximale Größe. Nehmen Sie Größenbegrenzungen in die Dokumentation Ihres Browsers auf.
- Die Laufzeitumgebung von WebSphere Application Server bearbeitet keine Cookies, die nicht von ihr selbst erstellt wurden.
Deshalb wird dieses
Cookie von der Laufzeitumgebung nicht verwendet.
- Wenn das SingleSignonToken-Objekt im Subjekt enthalten ist, wirkt es sich auf die Cachesuche nach dem
Subjekt aus, falls Sie mit der Methode "getUniqueID" etwas zurückgeben.
- Rufen Sie das HTTP-Cookie während der aus dem HTTP-Anforderungsobjekt oder aus einer Anwendung
ab. Der Beispielcode im Artikel Beispiel: HTTP-Cookie abrufen zeigt, wie Sie das
HTTP-Cookie aus der HTTP-Anforderung abrufen, das Cookie in die ursprünglichen Bytes entschlüsseln und aus den Bytes
Ihr angepasstes SingleSignonToken-Objekt erstellen können.
- Fügen Sie Ihr angepasstes Anmeldemodul zu den WebSphere Application Server-Konfigurationen für Systemanmeldung
hinzu, die bereits "com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule"
für den Empfang serialisierter Versionen Ihres angepassten Weitergabetokens enthalten. Da sich dieses Anmeldemodul auf Informationen im gemeinsam genutzten Status
verlassen muss, die vom Anmeldemodul "com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule" hinzugefügt wurden, sollten Sie dieses Anmeldemodul
hinter dem Anmeldemodul "com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule" hinzufügen.
Informationen zum Hinzufügen eines angepassten Anmeldemoduls zu vorhandenen Anmeldekonfigurationen finden Sie unter
"Angepasste Anmeldemodule für eine Systemanmeldekonfiguration für JAAS entwickeln".