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.

WebSphere Application Server unterstützt die folgenden TAI-Schnittstellen (Trust Association Interceptor):
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.
[z/OS]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.
Die Idee, dass WebSphere Application Server Trust-Associations unterstützen kann, impliziert, dass die Produktanwendungssicherheit HTTP-Anforderungen erkennt und verarbeitet, die vom Reverse-Proxy-Server empfangen werden. 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 Authentifizierungsrichtlinien auf jede Webanforderung anwendet, die an WebSphere Application Server übertragen wird. Diese Vertrauensstellung wird von den Interceptor-Funktionen validiert, die sich in der Produktumgebung für jede empfangene Anforderung befinden. Die Validierungsmethode wird von Proxy-Server und Interceptor vereinbart.

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).

Policy Director delegiert alle Webanforderungen an seine Webkomponente, den WebSEAL-Server. Eine der Hauptfunktionen des Servers ist die Authentifizierung des anfordernden Benutzers. Der WebSEAL-Server konsultiert ein LDAP-Verzeichnis (Lightweight Directory Access Protocol). Außerdem kann er die ursprüngliche Benutzer-ID einer anderen Benutzer-ID zuordnen, z. B., wenn eine globale Anmeldung verwendet wird.

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.
Die Junction, die im WebSEAL-Server erstellt wird, muss an den HTTP-Server weitergeleitet werden, der als Front-End für das Produkt dient. Der HTTP-Server weiß jedoch nicht, dass Trust-Association verwendet wird. Für den HTTP-Server ist das Produkt WebSEAL lediglich ein weiterer HTTP-Client, und im Rahmen seiner normalen Routinen sendet er die HTTP-Anforderung an das Produkt. Die einzige Voraussetzungen im HTTP-Server ist eine SSL-Konfiguration (Secure Sockets Layer), die nur die Serverauhentifizierung verwendet. Diese Voraussetzung schützt die Anforderungen, die über diese Junction übertragen werden.

Web Collaborator

Wenn Trust-Association aktiviert ist, verwaltet der Web-Collaborator die Interceptor, die im System konfiguriert sind. Der Web-Collaborator lädt und initialisiert diese Interceptor, wenn Sie Ihre Server erneut starten. Wenn eine Anforderung vom Web-Server an WebSphere Application Server übergeben wird, erhält der Web-Collaborator schließlich die Anforderung für eine Sicherheitsüberprüfung. Es müssen zwei Aktionen ausgeführt werden:
  1. Die Anforderung muss authentifiziert werden.
  2. Die Anforderung muss berechtigt werden.
Der Webauthentifikator wird aufgerufen, um die Anforderung durch Übergabe der HTTP-Anforderung zu authentifizieren. Bei erfolgreicher Authentifizierung wird ein Datensatz mit einem gültigen Berechtigungsnachweis vom Authenticator zurückgegeben, den der web Collaborator als Basis der Berechtigung für die angeforderte Ressource verwendet. Bei erfolgreicher Berechtigung zeigt der Web Collaborator WebSphere Application Server an, dass die Sicherheitsüberprüfung erfolgreich war und die angeforderte Ressource bereitgestellt werden kann.

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.

Anmerkung:

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.

Wenn ein Web-Server, wie z. B. IBM HTTP Server, einen TAI für die Kommunikation mit WebSphere Application Server verwendet, muss der TAI in manchen Fällen wissen, ob eine Anforderung über einen Web-Server oder eingegangen ist oder direkt an WebSphere Application Server übergeben wurde. Daher verwendet der Web-Container von WebSphere Application Server drei HttpServletRequest-Attribute, um dem TAI die Zertifikatsinformationen für eine Anforderung zur Verfügung zu stellen:
  • 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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_trust
Dateiname:csec_trust.html