Identitätszuordnung für die Berechtigung in Servern in unterschiedlichen Realms durchführen

Die Identitätszuordnung ist eine Eins-zu-eins-Zuordnung von Benutzeridentitäten, die zwischen zwei Servern stattfindet, damit nachgeschaltete Server korrekte Berechtigungsentscheidungen treffen können. Die Identitätszuordnung ist erforderlich, wenn Server mit anderen Benutzerregistrys, die nicht von mehreren Systemen gemeinsam benutzt werden, integriert werden müssen.

Informationen zu diesem Vorgang

In den meisten Fällen werden Anforderungen innerhalb einer Sicherheitsdomäne vom übergeordneten an den nachgeschalteten Server übertragen. In WebSphere Application Server sind zwei Server, die Member einer Zelle sind, gleichzeitig Member einer Sicherheitsdomäne. Innerhalb ihrer Zelle haben die beiden Server dieselbe Benutzerregistry und dieselben LTPA-Schlüssel (Lightweight Third Party Authentication) für die Tokenverschlüsselung. Diese beiden Gemeinsamkeiten stellen sicher, dass das LTPA-Token, unter anderen Benutzerattributen, das zwischen den beiden Servern weitergegeben wird, nicht nur entschlüsselt und geprüft werden kann, sondern dass die Benutzeridentität im Token auch den Attributen zugeordnet werden kann, die von der Engine für die Autorisierung erkannt werden.

Die zuverlässigste und daher empfohlene Konfiguration ist die Konfiguration zweier Server innerhalb einer Zelle. Manchmal müssen jedoch mehrere Systeme integriert werden, die nicht dieselbe Benutzerregistry verwenden können. Wenn zwei Server unterschiedliche Benutzerregistrys verwenden, stimmt die Sicherheitsdomäne des Zielservers nicht mit der des sendenden Servers überein.

WebSphere Application Server erlaubt die Zuordnung bevor die Anforderungen gesendet oder bevor die vorhandenen Sicherheitsberechtigungsnachweise an den Zielserver gesendet werden. Unter der Voraussetzung, dass der Zielrealm vertrauenswürdig ist, werden die Berechtigungsnachweise dem Eingangsserver zugeordnet.

Eine Alternative zur Zuordnung ist das Senden der Benutzeridentität ohne Token oder Kennwort an einen Zielserver ohne die Identität tatsächlich zuzuordnen. Die Verwendung der Benutzeridentität stützt sich in diesem Fall auf der gegenseitigen Anerkennung der Server. Verwenden Sie für die Zusicherung der Identität Common Secure Interoperability Version 2 (CSIV2). Ist CSIV2 aktiviert, wird nur das X.509-Zertifikat, der Name des Principals oder der DN gesendet, je nachdem, auf welche Weise der Ursprungsclient die erste Authentifizierung durchgeführt hat. Im Zuge der CSIv2-Identitätszusicherung akzeptieren sich die WAS-Server gegenseitig als vertrauenswürdige Server.

Die Zusicherung der Identität funktioniert nur, wenn die Benutzeridentität in der Zielbenutzerregistry vorhanden ist. Durch diesen Prozess kann auch eine Interoperabilität zwischen anderen Anwendungsservern, die mit J2EE ab Version 1.4 konform sind, erzielt werden. Ist sowohl im sendenden Server als auch im Zielserver die Identitätszusicherung konfiguriert, dann verwendet WebSphere Application Server immer dieselbe Authentifizierungsmethode, wenn sich beide Server in derselben Sicherheitsdomäne befinden. Weitere Informationen zur Zusicherung der Identität mit CSIV2 finden Sie im Artikel Zusicherung der Identität an den nachgeschalteten Server.

Ist die Benutzeridentität nicht in der Benutzerregistry des Zielservers enthalten, muss eine Identitätszuordnung erfolgen, bevor die Anforderung gesendet wird oder wenn die Anforderung eingeht. Diese Entscheidung hängt von Ihrer Umgebung und den damit verbundenen Bedingungen ab. In der Regel ist es jedoch aus folgenden Gründen einfacher, die Benutzeridentität vor dem Senden der Anforderung zuzuordnen:
  • Sie kennen die Benutzeridentität des vorhandenen Berechtigungsnachweises, weil sie aus der Benutzerregistry des sendenden Servers stammt.
  • Sie müssen sich keine Gedanken über LTPA-Schlüssel machen, die gemeinsam mit dem Zielrealm verwendet werden, weil die Identität nicht den LTPA-Berechtigungsnachweisen zugeordnet wird. Normalerweise wird die Identität einer Benutzer-ID und einem Kennwort in der Benutzerregistry des Zielrealms zugeordnet.
Sollten Sie sich für die Zuordnung auf dem senden System entscheiden, ist es in den meisten Fällen ratsam, die Integrität und Vertraulichkeit von Sicherheitsinformationen, die im Netz gesendet werden, mit SSL zu schützen. Wenn es keinen von den Servern gemeinsam benutzten LTPA-Schlüssel gibt, kann der Eingangsserver kein LTPA-Token auswerten. In diesem Fall muss die Zuordnung auf dem sendenden Server stattfinden, weil der Eingangsserver die Benutzeridentität nicht feststellen und somit keine Zuordnung eingehender Anforderungen durchführen kann. Weitere Informationen finden Sie im Artikel Identitätszuordnung für abgehende Anforderungen für einen anderen Zielrealm konfigurieren.

Wenn die Zuordnung auf dem Eingangsserver durchgeführt werden muss, möglicherweise aufgrund der Zuordnungsfunktionalität des Eingangsservers, müssen Sie sicherstellen, dass beide Server dieselben LTPA-Schlüssel haben, damit Sie auf die Benutzeridentität zugreifen können. Bei der sicheren Kommunikation zwischen Servern wird normalerweise für die Clientauthentifizierung ein LTPA-Token an den WSCredTokenCallback der eingehenden JAAS-Anmeldekonfiguration übergeben. Es gibt eine Methode für das Öffnen eines gültigen LTPA-Token, so dass auf die eindeutige Benutzer-ID zugegriffen werden kann und eine Zuordnung möglich ist. Weitere Informationen hierzu finden Sie im Artikel Identitätszuordnung für eingehende Anforderungen konfigurieren.In anderen Fällen, wie beispielsweise bei der Zusicherung der Identität, können Sie im Callback NameCallback der eingehenden Anmeldekonfiguration einen Benutzernamen empfangen, den Sie für die Identitätszuordnung verwenden können.

Dieser Abschnitt beschäftigt sich mit folgenden Themen:

Vorgehensweise


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_perfidmap
Dateiname:tsec_perfidmap.html