Angepasstes SSO-Token für die Weitergabe von Sicherheitsattributen implementieren

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:

Vorgehensweise

  1. 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][z/OS]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.

    [IBM i]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.

  2. 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.
  3. 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.
  4. 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".

Ergebnisse

Nach Ausführung dieser Schritte haben Sie ein angepasstes SSO-Token implementiert.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_custssoimpl
Dateiname:tsec_custssoimpl.html