Trust-Associations
Die Trust-Association ermöglicht die Integration der Sicherheit von IBM® WebSphere Application Server und Sicherheitsservern anderer Anbieter. Insbesondere kann ein Reverse-Proxy-Server als Front-End-Authentifizierungsserver arbeiten, während das Produkt seine eigene Berechtigungsrichtlinie auf die sich ergebenden Berechtigungsnachweise anwendet, die vom Proxy-Server weitergegeben werden.
Der Bedarf an einer solchen integrierten Konfiguration wird immer zwingender, besonders wenn ein einzelnes Produkt nicht alle Kundenbedürfnisse erfüllen kann oder eine Migration keine praktikable Lösung ist.
In dieser Konfiguration dient WebSphere Application Server mit seiner detaillierten Zugriffssteuerung als Back-End-Server. Der Reverse-Proxy-Server gibt die HTTP-Anforderung an WebSphere Application Server weiter, der die Berechtigungsnachweise des authentifizierten Benutzers enthält. WebSphere Application Server verwendet diese Berechtigungsnachweise für die Berechtigung der Anforderung.
Trust-Association-Modell
Die Idee, dass WebSphere Application Server Trust-Association unterstützen kann, setzt voraus, dass die Anwendungssicherheit des Produkts HTTP-Anforderungen erkennt und verarbeitet, die von einem Reverse-Proxy-Server stammen. WebSphere Application Server und der Proxy-Server gehen eine Vereinbarung ein, in der das Produkt dem Proxy-Server uneingeschränkt vertraut und der Proxy-Server seine Authentifizierungsrichtlinen auf jede Webanforderung anwendet, die an WebSphere Application Server übertragen wird. Dieses Vertrauen wird für jede empfangene Anforderung durch die Interceptor in der Produktumgebung validiert. Die Validierungsmethode wird zwischen Proxy-Server und Interceptor vereinbart.
Während WebSphere Application Server im Trust-Association-Modus ausgeführt wird, kann er weiterhin Anforderungen entgegennehmen, die nicht von einem Proxy-Server stammen. In diesem Fall wird kein Interceptor für die Validierung des Vertrauensverhältnisses benötigt.
- com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus
- Diese TAI-Interceptor-Implementierung, die die neue Schnittstelle für WebSphere Application Server implementiert,
unterstützt WebSphere Application Server 5.1.1 und höher. Die Schnittstelle unterstützt WebSEAL Version 5.1,
aber nicht WebSEAL Version 4.1. Informationen zur Weitergabe von Sicherheitsattributen finden Sie im Artikel
Weitergabe von Sicherheitsattributen.
Anmerkung: Die TAI-Interceptor-Implementierung unterstützt auch WebSphere Application Server for z/OS Version 5.1.0.2.
- com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl
- Dieser Interceptor ist neu in diesem Release. SPNEGO TAI wurde durch SPNEGO als Webauthentifikator für WebSphere Application Server ersetzt.

IBM WebSphere Application Server: WebSEAL Integration
Die Integration der Sicherheit von WebSEAL und WebSphere Application Server wird erreicht, indem der WebSEAL-Server am Front-End als Reverse-Proxy-Server installiert wird. Aus Sicht der WebSEAL-Verwaltung wird eine Junction mit WebSEAL an einem Ende und dem Web-Server des Produkts am anderen Ende erstellt. Eine Junction ist eine logische Verbindung, die erzeugt wird, um einen Pfad vom WebSEAL-Server zu einem anderen Server einzurichten.
In dieser Konfiguration wird eine Anforderung an Webressourcen, die in einer geschützten Domäne des Produkts gespeichert sind, an WebSEAL übergeben, wo sie anhand des Sicherheitsrealm von WebSEAL authentifiziert wird. Falls der anfordernde Benutzer Zugriff auf die Junction hat, wird die Anforderung über die Junction an den HTTP-Server von WebSphere Application Server und dann an den Anwendungsserver übertragen.
In der Zwischenzeit validiert WebSphere Application Server alle Anforderungen, die über die Junction eingehen, um sicherzustellen, dass die Quelle vertrauenswürdig ist. Dieser Prozess wird als Validierung des Vertrauensverhältnisses (oder Trustvalidierung) bezeichnet und von einem für das jeweilige Produkt bestimmten WebSeal-Interceptor durchgeführt. Bei erfolgreicher Validierung berechtigt WebSphere Application Server die Anforderung, indem er prüft, ob der Clientbenutzer die erforderlichen Berechtigungen für den Zugriff auf die Webressource hat. Wenn ja, wird die Webressource über den Web-Server an den WebSEAL-Server gesendet, der die Ressource dann an den Clientbenutzer weiterleitet.
WebSEAL-Server
Policy Director delegiert alle Webanforderungen an seine Webkomponente, den WebSEAL-Server. Eine der Hauptfunktionen des Servers ist es, die Authentifizierung des anfordernden Benutzers durchzuführen. Der WebSEAL-Server nimmt Verbindung zu einem LDAP-Verzeichnis (Lightweight Directory Access Protocol) auf. Er kann die ursprüngliche Benutzer-ID auch einer anderen Benutzer-ID zuordnen, z. B. bei der Verwendung von globalem SSO (Single Sign-On).

Für die Authentifizierung übernimmt der Server bei der Weiterleitung der Anforderung die Funktion eines Clients von WebSphere Application Server. Als solcher benötigt er eine eigene Benutzer-ID und ein Kennwort, um sich bei WebSphere Application Server zu identifizieren. Diese Identität muss im Sicherheitsrealm von WebSphere Application Server gültig sein. Der WebSEAL-Server ersetzt die Basisauthentifizierungsdaten in der HTTP-Anforderung durch seine eigene Benutzer-ID und sein Kennwort. Darüber hinaus muss WebSphere Application Server die Berechtigungsnachweise des anfordernden Clients bestimmen, damit der Anwendungsserver eine Identität hat, die er als Basis für die Berechtigungsentscheidungen verwenden kann. Diese Informationen werden über die HTTP-Anforderung übertragen. Dazu wird ein Header mit dem Namen iv-creds und den Benutzeridentitätsnachweisen von Tivoli Access Manager als Wert erstellt.
HTTP-Server
Die im WebSEAL-Server erstellte Junction muss an den HTTP-Server übertragen werden, der als Front-End des Produkts dient. Der HTTP-Server kann jedoch nicht erkennen, dass eine Trust-Association verwendet wird. Aus seiner Sicht ist WebSEAL lediglich ein weiterer HTTP-Client, und im Rahmen seiner normalen Routinen sendet er die HTTP-Anforderung an das Produkt. Die einzige Bedingung an den HTTP-Server ist eine SSL-Konfiguration (Secure Sockets Layer) mit reiner Serverauthentifizierung. Diese Bedingung schützt die Anforderungen, die sich innerhalb der Junction bewegen.
Web Collaborator
- Die Anforderung muss authentifiziert werden.
- Die Anforderung muss berechtigt werden.
Webauthentifikator
Der Webauthentifikator wird vom Web-Collaborator aufgefordert, eine bestimmte HTTP-Anforderung zu authentifizieren. Bei aktivierter Trust-Association ist es die Aufgabe des Webauthentifikators, den geeigneten Trust Association Interceptor zu ermitteln, an den die Anforderung zur Verarbeitung weitergeleitet wird. Dazu werden alle verfügbaren Interceptor abgefragt. Falls kein Zielinterceptor gefunden wird, verarbeitet der Webauthentifikator die Anforderung so, als sei keine Trust-Association aktiviert.
Die Produkte WebSphere Application Server Version 4 bis WebSphere Application Server Version 6.x unterstützen die Schnittstelle "com.ibm.websphere.security.TrustAssociationInterceptor.java". WebSphere Application Server Version 7.0.x und höher unterstützt die Schnittstelle "com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl".
TAI-Schnittstelle
Mit der TAI-Schnittstelle (Trust Association Interceptor) können Reverse-Proxy-Sicherheitsserver (RPSS, Reverse-Proxy Security Server) als ungeschützte Eingangspunkte für die Authentifizierung und eine grobe Berechtigung eingesetzt werden, während WebSphere Application Server die detaillierter Zugriffssteuerung durchführt. Trust-Associations verbessern die Sicherheit, indem sie Ausmaß und Risiken von Sicherheitslücken verringern.
In einer typischen E-Business-Infrastruktur besteht die verteilte Umgebung eines Unternehmens aus Webanwendungsservern, Web-Servern, vorhandenen Systemen und einem oder mehreren RPSS, wie z. B. dem Produkt Tivoli WebSEAL. Solche Reverse-Proxy-Server, Front-End-Sicherheitsserver oder Sicherheits-Plug-ins, die in Web-Servern registriert sind, überwachen die HTTP-Zugriffsanforderungen an die Web-Server und Webanwendungsserver. Die RPSS schützen den Zugriff auf die URIs (Uniform Resource Identifier), führen die Authentifizierung und eine grobe Berechtigung durch und leiten die Anforderung an den Zielanwendungsserver weiter.
- Das Attribut com.ibm.websphere.ssl.direct_connection_peer_certificates enthält ein X509Certificate[]-Objekt des Zertifikats für einen direkten Peer.
- Das Attribut com.ibm.websphere.ssl.direct_connection_cipher_suite enthält ein Zeichenfolgeobjekt einer direkten Cipher Suite.
- Das Attribut com.ibm.websphere.webcontainer.is_direct_connection enthält ein boolesches Objekt, das angibt, ob die Verbindung über einen Web-Server erfolgt ist oder direkt zu WebSphere Application Server hergestellt wurde.
Weitere Informationen zu diesen Attributen finden Sie im Artikel Anforderungsattribute des Web-Containers.