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]](../images/dist.gif)
SSO wird nur unterstützt,
wenn als Authentifizierungsverfahren LTPA (Lightweight Third Party Authentication) verwendet wird.
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.
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]](../images/linux.gif)
![[AIX HP-UX Solaris]](../images/unix.gif)
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.
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]](../images/dist.gif)
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:- Klicken Sie auf Sicherheit > Globale Sicherheit.
- 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:- Klicken Sie auf Sicherheit > Globale Sicherheit.
- 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
- Öffnen Sie die Administrationskonsole.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Geben Sie zum Aufrufen der Administrationskonsole in einem Web-Browser http://localhost:Portnummer/ibm/console ein.
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.
- Klicken Sie auf Sicherheit > Globale Sicherheit.
- Klicken Sie unter "Websicherheit" auf Single Sign-On (SSO).
- 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.
- Klicken Sie auf die Option Erfordert SSL, wenn davon auszugehen ist, dass für alle Anforderungen
HTTPS verwendet wird.
- 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.
- 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.
- 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.
- 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.