SSO für die Minimierung von Webbenutzerauthentifizierungen implementieren

Mit einem SSO-Token müssen sich Webbenutzer nur einmal authentifizieren, wenn Sie auf Webressourcen mehrerer WebSphere Application Server zugreifen. Anmeldeformulare für Webanwendungen erfordern, dass SSO aktiviert ist. Verwenden Sie diesen Artikel, wenn Sie Single Sign-On (SSO) erstmalig konfigurieren.

Vorbereitende Schritte

[AIX Solaris HP-UX Linux Windows][IBM i]SSO wird nur unterstützt, wenn als Authentifizierungsverfahren LTPA (Lightweight Third Party Authentication) verwendet wird.

[z/OS]SSO wird unterstützt, wenn als Authentifizierungsverfahren LTPA (Lightweight Third Party Authentication) verwendet wird.

Wenn SSO aktiviert ist, wird ein Cookie mit dem LTPA-Token erstellt und in die HTTP-Antwort eingefügt. Greift der Benutzer auf andere Webressourcen in einem anderen WebSphere Application Server-Prozess derselben DNS-Domäne zu, wird das Cookie in der Anforderung gesendet. Das LTPA-Token wird dann aus dem Cookie extrahiert und ausgewertet. Findet die Anforderung zwischen verschiedenen Zellen von WebSphere Application Server statt, funktioniert SSO nur, wenn die Zellen die LTPA-Schlüssel und die Benutzerregistry gemeinsam nutzen. Bei den Realmnamen der Systeme in der SSO-Domäne wird die Groß-/Kleinschreibung unterschieden und muss daher genau beachtet werden.

[Windows]Für LocalOS ist der Realmname identisch mit dem Domänennamen, sofern eine Domäne verwendet wird. Falls keine Domäne verwendet wird, entspricht der Realmname dem Maschinennamen.

[Linux][AIX HP-UX Solaris][IBM i]Der Realmname ist mit dem Hostnamen identisch.

Bei LDAP (Lightweight Directory Access Protocol) ist der Realmname der Name des 'host:port'-Realms des LDAP-Servers. Das Authentifizierungsverfahren LTPA erfordert, dass SSO aktiviert ist, wenn eine der Webanwendungen ein Anmeldeformular für die Authentifizierung verwendet.

Da SSO Teil von LTPA ist, sollten Sie den Artikel Lightweight Third Party Authentication lesen.

Wenn Sie die Weitergabe von Sicherheitsattributen aktivieren, wird das folgende Cookie zur Antwort hinzugefügt:
LtpaToken2
LtpaToken2 wird stärker verschlüsselt und ermöglicht das Hinzufügen mehrerer Attribute zum Token. Dieses Token enthält die Authentifizierungsidentität und weitere Informationen, z. B. die für die Verbindung zum Anmeldeserver verwendeten Attribute und den eindeutigen Cacheschlüssel für die Subject-Suche, sofern bei der Bestimmung der Eindeutigkeit nicht nur die Identität berücksichtigt wird.
Anmerkung: Wenn die Option Interoperabilitätsmodus aktiviert ist, kann das folgende Cookie zur Antwort hinzugefügt werden:
LtpaToken
LtpaToken wird für die Interoperation mit früheren Releases von WebSphere Application Server verwendet. Dieses Token enthält nur das Attribut für die Authentifizierungsidentität.
[z/OS]Anmerkung: LtpaToken wird für Releases vor WebSphere Application Server Version 5.1.0.2 generiert. LtpaToken2 wird für WebSphere Application Server Version 5.1.0.2 und höher generiert.
[AIX Solaris HP-UX Linux Windows][IBM i]Anmerkung: LtpaToken wird für Releases vor WebSphere Application Server Version 5.1.1 generiert. LtpaToken2 wird für WebSphere Application Server Version 5.1.1 und höher generiert.
Tabelle 1. LTPA-Tokentypen. In dieser Tabelle sind die LTPA-Tokentypen beschrieben.
Tokentyp Zweck Angabe
Nur LtpaToken2 Dies ist der Standardtokentyp. Er verwendet den Verschlüsselungsgrad AES-CBC-PKCS5 mit Auffüllung (128-Bit-Schlüsselgröße). Dieses Token ist stärker als das vor WebSphere Application Server Version 6.02 verwendete ältere LtpaToken. Diese Option wird empfohlen, wenn keine Interoperabilität mit älteren Releases erforderlich ist. Inaktivieren Sie in der Administrationskonsole in der SSO-Konfigurationsanzeige die Option Interoperabilitätsmodus. Diese Anzeige können Sie wie folgt aufrufen:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Klicken Sie unter "Websicherheit" auf Single Sign-On (SSO).
LtpaToken und LtpaToken2 Verwenden Sie diese Tokentypen für die Interoperabilität mit Vorgängerreleases von WebSphere Application Server Version 5.1.1. Das ältere LtpaToken-Cookie ist zusammen mit dem neuen LtpaToken2-Cookie vorhanden. Bei ordnungsgemäßer gemeinsamer Nutzung der LTPA-Schlüssel sollten Sie bei Auswahl dieser Option mit jeder Version von WebSphere interagieren können. Aktivieren Sie in der Administrationskonsole in der SSO-Konfigurationsanzeige die Option Interoperabilitätsmodus. Diese Anzeige können Sie wie folgt aufrufen:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Klicken Sie unter "Websicherheit" auf Single Sign-On (SSO).

Informationen zu diesem Vorgang

Die folgenden Schritte sind für das erstmalige Konfigurieren von SSO erforderlich.

Vorgehensweise

  1. Öffnen Sie die Administrationskonsole.

    [AIX Solaris HP-UX Linux Windows][z/OS]Geben Sie zum Aufrufen der Administrationskonsole in einem Web-Browser http://localhost:Portnummer/ibm/console ein.

    [IBM i]Geben Sie in einem Web-Browser http://Servername:Portnummer/ibm/console ein, um auf die Administrationskonsole zuzugreifen.

    Der Standardport für den Zugriff auf die Administrationskonsole ist 9060. Möglicherweise haben Sie jedoch während der Installation eine andere Portnummer angegeben. Geben Sie die richtige Portnummer ein.

  2. Klicken Sie auf Sicherheit > Globale Sicherheit.
  3. Klicken Sie unter "Websicherheit" auf Single Sign-On (SSO).
  4. Klicken Sie bei inaktiviertem SSO auf die Option Aktiviert. Nach dem Klicken auf Aktiviert müssen Sie die verbleibenden Schritte ausführen, um die Sicherheit zu aktivieren.
  5. Klicken Sie auf die Option Erfordert SSL, wenn davon auszugehen ist, dass für alle Anforderungen HTTPS verwendet wird.
  6. Geben Sie im Feld Domänenname den vollständig qualifizierten Namen der Domänen an, in denen SSO aktiviert ist. Wenn Sie Domänennamen angeben, müssen diese vollständig qualifiziert sein. Ist ein Domänenname nicht vollständig qualifiziert, setzt WebSphere Application Server keinen Domänennamenwert für das LtpaToken-Cookie, sodass SSO nur für den Server gilt, der das Cookie erstellt hat.

    Wenn Sie mehrere Domänen angeben möchten, können Sie die folgenden Trennzeichen verwenden: Semikolon (;), Leerzeichen ( ), Komma (,) oder Pipe-Zeichen (|). WebSphere Application Server durchsucht die angegebenen Domänen von links nach rechts. Jede Domäne wird mit dem Hostnamen in der HTTP-Anforderung verglichen, bis eine Übereinstimmung gefunden wird. Wenn Sie beispielsweise ibm.com;austin.ibm.com angeben und die erste Übereinstimmung in der Domäne ibm.com gefunden wird, setzt WebSphere Application Server die Operation nicht fort und sucht nicht nach einer Übereinstimmung in der Domäne "austin.ibm.com". Wird in den Domänen ibm.com oder "austin.ibm.com" keine Übereinstimmung gefunden, setzt WebSphere Application Server keine Domäne für das LtpaToken-Cookie.

    Tabelle 2. Werte für die Konfiguration des Felds "Domänenname".

    In dieser Tabelle sind die Werte für die Konfiguration des Felds "Domänenname" beschrieben.

    Typ des Domänennamens Beispiel Zweck
    Leer   Die Domäne ist nicht definiert. Dies bewirkt, dass der Browser die Domäne auf den Namen des Anforderungshosts setzt. Die Anmeldung ist in diesem Fall nur auf diesem Host gültig.
    Ein Domänenname austin.ibm.com Wenn die Anforderung für einen Host in der konfigurierten Domäne bestimmt ist, ist die Anmeldung für alle Hosts in dieser Domäne gültig. Andernfalls ist die Anmeldung nur für den Anforderungshost gültig.
    UseDomainFromURL UseDomainFromURL Wenn die Anforderung für einen Host in der konfigurierten Domäne bestimmt ist, ist die Anmeldung für alle Hosts in dieser Domäne gültig. Andernfalls ist die Anmeldung nur für den Anforderungshost gültig.
    Mehrere Domänennamen austin.ibm.com;raleigh.ibm.com Die Anmeldung ist für alle Hosts in der Domäne des Anforderungshosts gültig.
    Achtung: Domänenübergreifendes SSO (Single Sign-on) wird nicht unterstützt, wie z. B. bei chicago.xxx.com und cleveland.yyy.com (unterschiedliche DNS-Domänen).
    Mehrere Domänennamen und UseDomainFromURL austin.ibm.com;raleigh.ibm.com; UseDomainFromURL Die Anmeldung ist für alle Hosts in der Domäne des Anforderungshosts gültig.
    Achtung: Domänenübergreifendes SSO (Single Sign-on) wird nicht unterstützt, wie z. B. bei chicago.xxx.com und cleveland.yyy.com (unterschiedliche DNS-Domänen).
    Wenn Sie UseDomainFromURL angeben, setzt WebSphere Application Server den SSO-Domänennamen auf die Domäne des Hosts, der die Anforderung stellt. Kommt eine HTTP-Anforderung beispielsweise von "server1.raleigh.ibm.com", setzt WebSphere Application Server den SSO-Domänennamen auf raleigh.ibm.com.
    Tipp: Bei dem Wert UseDomainFromURL wird die Groß-/Kleinschreibung nicht interpretiert. Wenn Sie usedomainfromurl angeben, wird genau dieser Wert verwendet.

    Weitere Informationen hierzu finden Sie im Artikel SSO-Einstellungen.

  7. Optional: Aktivieren Sie die Option Interoperabilitätsmodus, wenn SSO-Verbindungen in WebSphere Application Server ab Version 5.1.1 mit früheren Versionen des Anwendungsservers in der Lage sein sollen, mit älteren Versionen des Anwendungsservers zu interagieren.

    Diese Option fügt in die Antwort das veraltete LtpaToken ein, damit die Antwort an Server gesendet werden kann, die nur mit diesem Tokentyp arbeiten. Sonst wird nur LtpaToken2 zur Antwort hinzugefügt.

    Wenn Leistungsaspekte zu berücksichtigen sind und Sie eine Verbindung zu Servern der Version 6.1 oder höher herstellen möchten, die keine von LtpaToken abhängigen Produkte ausführen, sollten Sie den Interoperabilitätsmodus nicht aktivieren. Ist der Interoperabilitätsmodus nicht aktiviert, wird kein LtpaToken in einer Antwort zurückgegeben.

  8. Optional: Aktivieren Sie die Option Weitergabe der Sicherheitsattribute für eingehende Webanforderungen, wenn während der Anmeldung bei einem bestimmten Front-End-Server Informationen für die Weitergabe an andere Front-End-Server hinzugefügt werden sollen. Das SSO-Token enthält keine sensiblen Attribute, erkennt jedoch, wo sich der ursprüngliche Anmeldeserver befindet. Dies ist notwendig, falls zu diesem Server eine Verbindung hergestellt werden muss, um serialisierte Informationen abzurufen. Es enthält außerdem den Wert, mit dem die serialisierten Informationen in DynaCache gesucht werden, wenn beide Front-End-Server in derselben DRS-Replikationsdomäne konfiguriert sind. Weitere Informationen finden Sie unter Weitergabe von Sicherheitsattributen.
    Wichtig: Wenn die folgenden Aussagen für Sie zutreffen, sollten Sie zur Aufrechterhaltung der Leistung die Option Weitergabe von Sicherheitsattributen für eingehende Webanforderungen inaktivieren:
    • Sie müssen während einer Anmeldung keine spezifischen Informationen zum Subject hinzufügen, die nicht von einem anderen Front-End-Server abgerufen werden könnten.
    • Sie haben mit den WSSecurityHelper-APIs keine angepassten Attribute zum PropagationToken hinzugefügt.
    Falls Sie feststellen, dass angepasste Informationen im Subject fehlen, können Sie die Option Weitergabe von Sicherheitsattributen für eingehende Webanforderungen wieder aktivieren, um festzustellen, ob die Informationen dann fehlerfrei an andere Front-End-Anwendungsservern weitergegeben werden.
    Mit den beiden folgenden angepassten Eigenschaften können Sie unter Umständen die Leistung steigern, wenn die Weitergabe von Sicherheitsattributen aktiviert ist:
    • com.ibm.CSI.propagateFirstCallerOnly

      Der Standardwert dieser Eigenschaft ist true. Wenn diese angepasste Eigenschaft auf true gesetzt ist, wird bei aktivierter Weitergabe von Sicherheitsattributen der erste Caller im Weitergabetoken, der im Thread bleibt, protokolliert. Wenn diese Eigenschaft auf false gesetzt wird, werden Wechsel des Callers protokolliert. Dies kann sich negativ auf die Leistung auswirken.

    • com.ibm.CSI.disablePropagationCallerList

      Wenn diese angepasste Eigenschaft auf true gesetzt ist, gibt es keine Möglichkeit, eine Caller-Liste oder Hostliste zum Weitergabetoken hinzuzufügen. Diese Funktion ist von Vorteil, wenn die Caller-Liste oder Hostliste im Weitergabetoken in der Umgebung nicht benötigt wird.

  9. Klicken Sie auf OK.

Nächste Schritte

Damit die Änderungen wirksam werden, müssen Sie alle Produkt-Deployment-Manager, -knoten und -server speichern, stoppen und anschließend erneut starten.


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_msso
Dateiname:tsec_msso.html