Ein Standardweitergabetoken befindet sich im aktiven Thread für Anwendungen und in der
Sicherheitsinfrastruktur, die verwendet werden soll.
Dieses Standardweitergabetoken wird vom Produkt
an untergeordnete Komponenten weitergegeben, und das Token bleibt in dem Thread, in dem der
Aufruf nach jedem Hop ankommt.
Informationen zu diesem Vorgang
Der Zugriff auf die Daten sollte aus dem Container jeder Ressource
möglich sein, die das Weitergabetoken empfängt.
Damit die Weitergabe ordnungsgemäß funktioniert, muss das Weitergabefeature in
jedem Server, an den eine Anforderung gesendet wird, aktiviert sein.
Vergewissern Sie sich, dass Sie die Weitergabe der Sicherheitsattribute für alle Zellen in Ihrer Umgebung,
für die Sie eine Weitergabe wünschen, aktiviert haben.
Eine
WSSecurityHelper-Klasse ist vorhanden, die APIs für den Zugriff
auf PropagationToken-Attribute enthält.
Dieser Artikel enthält Szenarien für den Einsatz des Weitergabetoken und entsprechende
Beispiele.
Es besteht eine enge Beziehung zwischen dem Weitergabetoken und dem Feature für Arbeitsbereiche.
Der Hauptunterschied zwischen diesen Features besteht darin, dass nach dem
Hinzufügen von Attributen zum
Weitergabetoken diese Attribute nicht mehr geändert werden können.
Diese Attribute können deshalb nicht mehr geändert werden, damit
die Sicherheitslaufzeit prüfbare Informationen hinzufügen kann
und diese Informationen während der Dauer des Aufrufs dort verbleiben können.
Jedesmal, wenn Sie ein Attribut zu einem bestimmten Schlüssel hinzufügen, wird
ein ArrayList-Objekt gespeichert, die das betreffende Attribut enthält.
Jedes neue Attribut, das mit demselben Schlüssel hinzugefügt wird, wird dem
ArrayList-Objekt hinzugefügt.
Wenn Sie getAttributes aufrufen, wird das ArrayList-Objekt in einen Zeichenfolge-Array
(String[]) umgewandelt, und die Reihenfolge der Attribute wird beibehalten.
Das erste Element im Zeichenfolge-Array ist das erste Attribut, das für den
betreffenden Schlüssel hinzugefügt wurde.
Im Standardweitergabetoken
existiert ein Änderungs-Flag, das alle Datenänderungen im Token protokolliert.
Diese Änderungen werden protokolliert, damit WebSphere Application Server
weiß, wann die Authentifizierungsinformationen erneut gesendet werden müssen, damit der nachgeschaltete Server diese Änderungen erhält.
Normalerweise wird für einen authentifizierten Client
mit Common Secure Interoperability Version 2 (CSIv2)
eine Sitzung zwischen den Servern verwaltet.
Ändert sich das Weitergabetoken, wird eine neue Sitzung generiert
und folglich findet eine neue Authentifizierung statt.
Häufige Änderungen des Weitergabetoken innerhalb einer Methode
verursachen häufige Downstream-Aufrufe.
Falls Sie das Token ändern, bevor Sie viele Downstream-Aufrufe ausführen,
oder das Token zwischen den Downstream-Aufrufen ändern,
kann dies die Sicherheit beeinträchtigen.
- Rufen Sie die Serverliste aus dem Standardweitergabetoken ab.
Jedesmal, wenn
das Weitergabetoken (horizontal oder downstream) weitergegeben und zum Erstellen des authentifizierten Subjekts
verwendet wird, wird der Name des empfangenden Anwendungsservers im Weitergabetoken
protokolliert.
Das Format für den Host ist Zelle:Knoten:Server. Es enthält
den Zellennamen, den Knotennamen und den Servernamen jedes Anwendungsservers, der
den Aufruf erhält.
Der folgende Code ruft diese Liste mit Namen ab und kann
über eine J2EE-Anwendung (Java™ 2 Platform, Enterprise
Edition) aufgerufen werden.
Jeder Server in der Liste hat das folgende Format:
Zelle:Knotenname:Servername.
Die Ausgabe lautet z. B. wie folgt: meinManager:node1:server1
String[] server_list = null;
// Ist die Sicherheit auf diesem Anwendungsserver inaktiviert, nicht prüfen.
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Ruft den Zeichenfolgebereich server_list ab.
server_list = com.ibm.websphere.security.WSSecurityHelper.getServerList();
}
catch (Exception e)
{
// Führt eine normale Ausnahmebehandlung für Ihre Anwendung durch
}
if (server_list != null)
{
// Jeden Server in der Liste anzeigen, server_list[0] ist der erste Server.
for (int i=0; i<server_list.length; i++)
{
System.out.println("Server[" + i + "] = " + server_list[i]);
}
}
}
- Rufen Sie die Liste der Caller (Aufrufenden) über die API "getCallerList" ab.
Jedesmal,
wenn ein authentifizierter Benutzer im aktiven Thread festgelegt wird oder
versucht wird, Attribute zum Weitergabetoken hinzuzufügen,
wird ein Standardweitergabetoken generiert.
Wenn ein authentifizierter Benutzer im Thread festgelegt wird, wird der Benutzer
im Standardweitergabetoken protokolliert.
Falls der RunAs-Benutzer mit mit dem Caller (Aufrufenden) übereinstimmt,
kann derselbe Benutzer mehrere Male protokolliert werden.
Die folgende Liste enthält die Regeln, anhand deren ermittelt wird,
ob ein zum Thread hinzugefügter Benutzer im
Weitergabetoken protokolliert wird:
- Das aktuelle Subjekt muss authentifiziert sein. Ein nicht authentifiziertes Subjekt wird
beispielsweise nicht protokolliert.
- Das aktuelle authentifizierte Subjekt wird protokolliert,
falls zuvor kein Subjekt protokolliert wurde.
- Das aktuelle authentifizierte Subjekt wird protokolliert,
falls das zuletzt protokollierte authentifizierte Subjekt nicht denselben Benutzer enthält.
- Das aktuelle authentifizierte Subjekt wird auf jedem eindeutigen Anwendungsserver
innerhalb des Weitergabeprozesses
protokolliert.
Das folgende Codebeispiel veranschaulicht, wie die API "getCallerList" verwendet wird.
Jeder Caller (Aufrufende) in der Liste hat das folgende Format:
Zelle:Knotenname:Servername:Realm:Portnummer/Sicherheitsname. Die Ausgabe lautet z. B. wie folgt: meinManager:node1:server1:ldap.austin.ibm.com:389/jsmith.
String[] caller_list = null;
// Ist die Sicherheit auf diesem Anwendungsserver inaktiviert, die Liste der Caller nicht prüfen.
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Ruft das String-Array für caller_list ab
caller_list = com.ibm.websphere.security.WSSecurityHelper.getCallerList();
}
catch (Exception e)
{
// Führt eine normale Ausnahmebehandlung für Ihre Anwendung durch
}
if (caller_list != null)
{
// Gibt jeden Caller in der Liste aus, caller_list[0] ist der erste Caller
for (int i=0; i<caller_list.length;i++)
{
System.out.println("Caller[" + i + "] = " + caller_list[i]);
}
}
}
- Rufen Sie den Sicherheitsnamen des ersten authentifizierten Benutzers über die API "getFirstCaller" ab.
Wenn Sie feststellen möchten,
welcher authentifizierte Caller (Aufrufende) die Anforderung gestartet hat, können Sie die
Methode "getFirstCaller" aufrufen, und die Liste der Caller wird ausgewertet.
Diese Methode gibt jedoch nur den Sicherheitsnamen des Callers zurück.
Wenn Sie weitere Informationen als nur den Sicherheitsnamen benötigen,
rufen Sie die Methode "getCallerList" auf, und rufen Sie den ersten Eintrag
im Zeichenfolge-Array ab.
Dieser Eintrag enthält alle Informationen zum Caller.
Im folgenden Codebeispiel wird der Sicherheitsname
des ersten authentifizierten Callers mit der API
"getFirstCaller" abgerufen.
Die Ausgabe lautet z. B. wie folgt:
jsmith.
String first_caller = null;
// Ist die Sicherheit auf diesem Anwendungsserver inaktiviert, nicht prüfen.
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Ruft den ersten Caller ab
first_caller = com.ibm.websphere.security.WSSecurityHelper.getFirstCaller();
// Gibt den Namen des Callers aus
System.out.println("First caller: " + first_caller);
}
catch (Exception e)
{
// Führt eine normale Ausnahmebehandlung für Ihre Anwendung durch
}
}
- Rufen Sie den Namen des ersten Anwendungsservers für eine Anforderung über die Methode "getFirstServer" ab.
Wenn Sie
feststellen möchten, welches der
erste Anwendungsserver für diese Anforderung ist, können Sie die Methode
getFirstServer direkt aufrufen.
Im folgenden Codebeispiel wird der Name des ersten Anwendungsservers
mit der API "getFirstServer" abgerufen.
Die Ausgabe lautet z. B. wie folgt: meinManager:node1:server1.
String first_server = null;
// Ist die Sicherheit auf diesem Anwendungsserver inaktiviert, nicht prüfen.
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Ruft den ersten Server ab.
first_server = com.ibm.websphere.security.WSSecurityHelper.getFirstServer();
// Zeigt den Servernamen an.
System.out.println("First server: " + first_server);
}
catch (Exception e)
{
// Führt eine normale Ausnahmebehandlung für Ihre Anwendung durch
}
}
- Fügen Sie dem Standardweitergabetoken über die API "addPropagationAttribute" Attribute hinzu.
Sie können dem
Standardweitergabetoken angepasste Attribute hinzufügen.
Dieses Token folgt der Anforderung an die nachgeschalteten Server, so dass die Attribute
verfügbar sind, wenn sie benötigt werden.
Wenn Sie zum Hinzufügen von Attributen das
Standardweitergabetoken verwenden, müssen Sie die
folgenden Voraussetzungen beachten:
- Das Hinzufügen von Informationen zum Weitergabetoken wirkt sich auf das CSIv2-Sitzungs-Caching aus.
Zwischen Anforderungen an ein fernes System sollten Sie
Informationen sparsam hinzufügen.
- Nachdem Sie Informationen mit einem bestimmten Schlüssel hinzugefügt haben,
können diese nicht entfernt werden.
- Sie können einem bestimmten Schlüssel
beliebig viele Werte hinzufügen. Alle Werte müssen
in einem zurückgegebenen Zeichenfolge-Array jedoch in der Reihenfolge
verfügbar sein, in der sie hinzugefügt wurden.
- Das Weitergabetoken ist nur auf Servern verfügbar,
auf denen die Weitergabe und die Sicherheit aktiviert sind.
- Damit Attribute zum Standardweitergabetoken hinzugefügt werden können, ist das
die Java-2-Sicherheitsattribut
"wssecurity.addPropagationAttribute" von "javax.security.auth.AuthPermission" erforderlich.
- Eine Anwendung kann keine Schlüssel verwenden, die mit
com.ibm.websphere.security oder mit
com.ibm.wsspi.security beginnen.
Diese Präfixe sind für das System reserviert.
Das folgende Codebeispiel zeigt die Verwendung der API "addPropagationAttribute".
// Ist die Sicherheit auf diesem Anwendungsserver inaktiviert,
// den Status der Serversicherheit nicht prüfen.
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
// Gibt den Schlüssel und die Werte an.
String key = "mykey";
String value1 = "value1";
String value2 = "value2";
// Legt key, value1 fest.
com.ibm.websphere.security.WSSecurityHelper.
addPropagationAttribute (key, value1);
// Legt key, value2 fest.
String[] previous_values = com.ibm.websphere.security.WSSecurityHelper.
addPropagationAttribute (key, value2);
// Anmerkung: previous_values sollte value1 enthalten.
}
catch (Exception e)
{
// Führt eine normale Ausnahmebehandlung für Ihre Anwendung durch
}
}
- Rufen Sie die angepassten Attribute über die API "getPropagationAttributes" ab.
Angepasste Attribute werden mit der API
"addPropagationAttribute" zum Standardweitergabetoken hinzugefügt.
Diese Attribute können mit der API "getPropagationAttributes" abgerufen werden.
Dieses Token folgt der Anforderung an die nachgeschalteten Server, so dass die Attribute
verfügbar sind, wenn sie benötigt werden.
Wenn Sie zum Abrufen von Attributen das Standardweitergabetoken verwenden, müssen Sie die
folgenden Voraussetzungen beachten:
- Das Weitergabetoken ist nur auf Servern verfügbar,
auf denen die Weitergabe und die Sicherheit aktiviert sind.
- Damit Attribute aus dem Standardweitergabetoken abgerufen werden können,
ist die Java-2-Sicherheitsberechtigung
"wssecurity.getPropagationAttributes" von "javax.security.auth.AuthPermission" erforderlich.
Informationen zum Hinzufügen von Attributen mit der API
"addPropagationAttributes" finden Sie im Abschnitt Dem Standard-PropagationToken angepasste Attribute
hinzufügen.
Das folgende Codebeispiel zeigt die Verwendung der API "getPropagationAttributes".
// Ist die Sicherheit auf diesem Anwendungsserver inaktiviert, nicht prüfen.
if (com.ibm.websphere.security.WSSecurityHelper.isServerSecurityEnabled())
{
try
{
String key = "mykey";
String[] values = null;
// Legt key, value1 fest.
values = com.ibm.websphere.security.WSSecurityHelper.
getPropagationAttributes (key);
// Zeigt die Werte an.
for (int i=0; i<values.length; i++)
{
System.out.println("Value[" + i + "] = " + values[i]);
}
}
catch (Exception e)
{
// Führt eine normale Ausnahmebehandlung für Ihre Anwendung durch
}
}
Die Ausgabe lautet z. B. wie folgt:
Value[0] = value1
Value[1] = value2
- Ändern Sie die Konfiguration für die Weitergabetokenfactory so, dass eine andere Factory als die Standardtokenfactory verwendet wird.
Wenn WebSphere Application Server
ein Standardweitergabetoken generiert, verwendet Application Server
die Klasse "TokenFactory", die in der Eigenschaft "com.ibm.wsspi.security.token.propagationTokenFactory" angegeben ist.
Die Standardtokenfactory für diese Eigenschaft ist "com.ibm.ws.security.ltpa.AuthzPropTokenFactory". Diese
Tokenfactory codiert die Daten im Weitergabetoken und verschlüsselt sie nicht.
Da das Weitergabetoken normalerweise mittels SSL (Secure Sockets Layer) über
CSIv2 (Common Secure Interoperability Version 2) weitergegeben wird, muss das Token selbst nicht verschlüsselt werden.
Sollten Sie jedoch zusätzliche Sicherheit für das Weitergabetoken benötigen, können Sie
diese Eigenschaft eine andere Token-Factory-Implementierung zuordnen, um das Token zu verschlüsseln.
Wenn Sie der Eigenschaft beispielsweise die Tokenfactory "com.ibm.ws.security.ltpa.LTPAToken2Factory" zuordnen, wird das Token mit
AES verschlüsselt. Sie müssen jedoch die Leistungsvorteile gegen Ihre Sicherheitsanforderungen abwägen.
Werden dem Weitergabetoken kritische Daten hinzugefügt, ist dies ein Grund dafür,
die Token-Factory-Implementierung so zu ändern, dass das Token verschlüsselt und nicht nur codiert wird.
- Öffnen Sie die Administrationskonsole.
- Klicken Sie auf Sicherheit > Globale Sicherheit.
- Klicken Sie auf Angepasste Eigenschaften.
- Führen Sie Ihre eigene Prozedur für Signatur und Verschlüsselung des Standardweitergabetokens aus.
Wenn Sie eigene
Signatur- und Verschlüsselungsverfahren auf das Standardweitergabetoken anwenden müssen, ist eine Implementierung der
folgenden Klassen erforderlich:
- com.ibm.wsspi.security.ltpa.Token
- com.ibm.wsspi.security.ltpa.TokenFactory
Ihre Token-Factory-Implementierung instanziiert und validiert die Tokenimplementierung.
Sie können die an die Initialisierungsmethode der Tokenfactory übergebenen LTPA-Schlüssel oder eigene Schlüssel verwenden.
Wenn Sie Ihre eigenen Schlüssel verwenden, müssen diese überall gleich sein, damit die Token, die mit diesen Schlüsseln generiert werden,
validiert werden können.
Nähere Informationen zum Implementieren einer eigenen, angepassten Tokenfactory finden Sie der
API-Dokumentation, die Sie über einen Link auf der Titelseite des Information Center aufrufen können.
- Ordnen Sie dem Standardweitergabetoken Ihre Tokenfactory zu.
- Öffnen Sie die Administrationskonsole.
- Klicken Sie auf Sicherheit > Globale Sicherheit.
- Klicken Sie auf Angepasste Eigenschaften.
- Suchen Sie die Eigenschaft "com.ibm.wsspi.security.token.propagationTokenFactory", und vergewissern Sie sich, dass der Wert dieser
Eigenschaft Ihrer eigenen Token-Factory-Implementierung
entspricht.
- Prüfen Sie, ob Ihre Implementierungsklassen im Verzeichnis
Stammverzeichnis_des_Anwendungsservers/classes gespeichert werden, damit
der Klassenlader von WebSphere Application Server
die Klassen laden kann.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Vergewissern Sie sich, dass die Implementierungsklassen im Verzeichnis
${USER_INSTALL_ROOT}/classes enthalten sind, so dass das Klassenladeprogramm von WebSphere Application Server
diese Klassen laden kann.
Vergewissern Sie sich, dass das Benutzerprofil QEJBSVR Lese-, Schreib- und Ausführungsrechte
(*RWX) das Verzeichnis "classes" besitzt. Mit dem Befehl "Work
with Authority (WRKAUT)" können Sie die Berechtigungen für das Verzeichnis anzeigen.