In der Konfiguration können Sie für die Sicherheit eingehender und abgehender Daten verschiedene
Transporte festlegen.
Vorbereitende Schritte
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Transport für eingehende Verbindungen bezieht sich auf die Art der Listener-Ports, die für den Empfang von Anforderungen an diesen
Server geöffnet werden, und auf die Attribute dieser Ports. Common Secure Interoperability Specification
Version 2 (CSIv2) und Secure Authentication Service (SAS) können den Transport konfigurieren.
Wichtig: SAS wird nur zwischen Servern der Version 6.0.x und Servern früherer Versionen unterstützt, die in eine Zelle der Version 6.1 eingebunden sind.
Transport für eingehende Verbindungen bezieht sich auf die Art der Listener-Ports, die für den Empfang von Anforderungen an diesen
Server geöffnet werden, und auf die Attribute dieser Ports. Common Secure Interoperability Specification
Version 2 (CSIv2) und
z/OS Secure Authentication Service (z/SAS) können den Transport konfigurieren.
Wichtig: z/SAS wird nur zwischen Servern der Version 6.0.x und früheren Versionen unterstützt, die in eine Zelle der Version 6.1 eingebunden wurden.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Die beiden Protokolle unterscheiden sich jedoch wie folgt:
- CSIv2 ist allerdings viel flexibler als SAS, weil SAS SSL (Secure Socket Layer) erfordert; CSIv2 jedoch nicht.
- SAS bietet im Gegensatz zu CSIv2
keine Unterstützung
für die SSL-Authentifizierung mit Clientzertifikat.
- CSIv2 kann SSL-Verbindungen anfordern, SAS
unterstützt dagegen ausschließlich SSL-Verbindungen.
- Bei SAS sind stets zwei Listener-Ports geöffnet: TCP/IP und SSL.
- Bei
CSIv2 muss nicht mehr als ein Listener-Port geöffnet sein, es können jedoch bis zu drei
Listener-Ports offen sein. Sie können einen Port für TCP/IP und für den Fall öffnen, dass SSL erforderlich ist. Sie können zwei Ports
öffnen, wenn SSL unterstützt wird, und drei Ports, wenn SSL und die SSL-Authentifizierung mit Clientzertifikat
unterstützt werden.
CSIv2 und z/SAS unterstützen fast dieselben Funktionen.
CSIv2 hat den Vorteil der Interoperabilität mit anderen Produkten von WebSphere Application Server
und anderen Plattformen, die das Protokoll CSIv2 unterstützen.
Informationen zu diesem Vorgang
Führen Sie die folgenden Schritte aus, um die Einstellungen für eingehende Transporte in der
Administrationskonsole zu konfigurieren:
Vorgehensweise
- Klicken Sie auf Sicherheit > Globale Sicherheit.
- Klicken Sie unter "RMI/IIOP-Sicherheit" auf Eingehende CSIv2-Kommunikation.
- Wählen Sie unter "Transport" die Option SSL erforderlich aus. Sie können als Transportverfahren für eingehende Nachrichten, die ein Server unterstützen soll, SSL
und/oder TCP/IP festlegen. Bei Angabe von TCP/IP legen Sie fest, dass der Server nur TCP/IP
unterstützt und keine SSL-Verbindungen empfangen kann. Wenn Sie SSL unterstützt angeben, kann der
Server TCP/IP- und SSL-Verbindungen unterstützen. Bei Angabe
von SSL erforderlich legen Sie fest, dass jeder Server, der mit diesem Server
kommuniziert, SSL verwenden muss.
- Klicken Sie auf Anwenden.
- Überlegen Sie, die konfigurierten Listener-Ports festzulegen.
Klicken Sie für einen Anwendungsserver auf Server > Anwendungsserver
> Servername. Klicken Sie unter "Kommunikation"
auf Ports. Die Anzeige "Ports" für den angegebenen Server erscheint.
Für einen Node Agent klicken Sie auf
Systemverwaltung > Node Agents > Knotenname.
Klicken Sie unter "Weitere Eigenschaften" auf Ports. Die
Anzeige "Ports" für den Node Agent und den
Deployment Manager wurde bereits korrigiert. Bei Bedarf können Sie jedoch die Ports
neu zuordnen. Für den Deployment Manager klicken Sie auf Systemverwaltung > Deployment
Manager. Klicken Sie unter
Weitere Eigenschaften auf Ports.
Der ORB (Object Request Broker) in WebSphere Application Server
verwendet einen Listener-Port für die RMI/IIOP-Kommunikation (Remote Method Invocation over the Internet Inter-ORB Protocol)
und wird während er Migration statisch mit Konfigurationsdialogen angegeben.
ORB_LISTENER_ADDRESS und BOOTSTRAP_ADDRESS müssen denselben Port angeben.Wenn Sie
mit einer Firewall arbeiten, müssen Sie einen statischen Port für den ORB-Listener angeben und diesen Port in der Firewall öffnen, so dass
eine Kommunikation über den angegebenen Port stattfinden kann.
Die Endpunkteigenschaft für die Einstellung des ORB-Listener-Ports ist ORB_LISTENER_ADDRESS.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
In
der Umgebung mit
WebSphere Application Server Network Deployment wird die Endpunkteigenschaft
ORB_LISTENER_ADDRESS
auf dem Node Agent definiert. Der Location Service Daemon (LSD)
befindet sich auf dem Node Agent und lehnt sich an den ORB-Listener-Port an. Deshalb muss
der Port fest definiert werden. Außerdem müssen Sie die Eigenschaft ORB_LISTENER_ADDRESS
den anderen Anwendungsservern hinzufügen, um deren ORB-Listener-Port festzulegen. Jeder ORB hat einen eigenen Listener-Port. In
WebSphere Application Server Network Deployment
müssen Sie einen anderen Listener-Port angeben. Sie können beispielsweise die folgenden Ports festlegen:
- Node Agent: ORB_LISTENER_ADDRESS=9000
- Server1: ORB_LISTENER_ADDRESS=9811
- Server2: ORB_LISTENER_ADDRESS=9812
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Verbundserver
können ausgeführt werden, ohne dass der Node Agent aktiv ist. Ist ORB_LISTENER_ADDRESS auf 0 oder einen höheren Wert gesetzt,
ist der Server nicht davon abhängig, dass der Location Service Daemon (LSD) Verbindungen an den Server weiterleitet. Wenn Sie
die Eigenschaft ORB_LISTENER_ADDRESS definieren, geben alle Objektreferenzen
im Namespace die Verbindung zum Server an und nicht der Location Service Daemon. Wird der Server ohne den Node Agent ausgeführt, müssen alle Anwendungen über den Namensserver im Anwendungsserver
aufgerufen werden. Der Client muss die JNDI-Referenz (Java™ Naming
Directory Interface)
ändern, damit Host und Port des Anwendungsservers verwendet werden.
Tabelle 1. ORB_LISTENER_ADDRESS. In dieser Tabelle ist die Eigenschaft ORB_LISTENER_ADDRESS beschrieben.ORB_LISTENER_ADDRESS |
|
Wert = 0 |
Der Server wird an einem verfügbaren Port gestartet und verwendet den Location Service Daemon nicht. |
Wert > 0 |
Der Server startet an dem von Ihnen angegebenen Port. Der
Location Service Daemon wird nicht verwendet. |
Anmerkung: Das Workload-Management funktioniert möglicherweise nicht, wenn der Node Agent nicht aktiv ist.
Führen Sie die folgenden Schritte in der Administrationskonsole aus, um die
ORB_LISTENER_ADDRESS-Ports anzugeben.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Führen Sie die folgenden Schritte für den Node Agent und den Deployment Manager aus.
- Klicken Sie auf Server > Anwendungsserver > Servername. Klicken Sie unter "Kommunikation"
auf Ports > Neu.
- Wählen Sie in der Anzeige "Konfiguration" im Feld Portname den Wert ORB_LISTENER_ADDRESS aus.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Geben Sie die IP-Adresse, den vollständig qualifizierten DNS-Hostnamen oder nur den DNS-Hostnamen im Feld
Host ein. Beispiel: Wenn der Hostname meinhost ist, kann der vollständig qualifizierte DNS-Name
meinhost.meineco.com und die IP-Adresse 155.123.88.201 sein.
Geben Sie im Feld Host die IP-Adresse oder "*" ein. Ein Beispiel für die IP-Adresse ist 155.123.88.201.
Wichtig: DNS-Hostnamen werden als Wert für die Eigenschaft ORB_LISTENER_ADDRESS
nicht unterstützt.
- Geben Sie im Feld Port die Portnummer ein. Die angegebene Portnummer
definiert den Port, an dem der Service Clientanforderungen empfangen soll. Der Portwert wird zusammen mit dem Hostnamen verwendet. Im vorherigen Beispiel könnte die Portnummer 9000 sein.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Klicken Sie auf Sicherheit > Globale Sicherheit. Klicken Sie unter "RMI/IIOP-Sicherheit"
auf Eingehende CSIv2-Kommunikation. Wählen Sie die für eingehende Anforderungen von CSIv2-Clients die SSL-Einstellungen aus. Klicken Sie dann
auf Anwenden. Das Protokoll CSIv2 wird
für die Interoperabilität mit früheren Releases verwendet. Wenn Sie die Keystore- und Truststore-Dateien in der SSL-Konfiguration konfigurieren,
enthalten diese Dateien die richtigen Informationen für die Interoperabilität mit früheren Releases von
WebSphere Application Server.
Klicken Sie auf Sicherheit > Globale Sicherheit. Klicken Sie unter
"RMI/IIOP-Sicherheit" auf Authentifizierung gemäß z/SAS, um die
SSL-Einstellungen für eingehende Anforderungen von z/SAS-Clients auszuwählen.
Ergebnisse
Damit ist die Konfiguration des Transports für eingehende Verbindungen abgeschlossen.
In der Konfiguration können Sie für die Sicherheit eingehender und abgehender Daten verschiedene
Transporte festlegen. Wenn der Anwendungsserver beispielsweise der erste von Benutzern verwendete Server ist,
muss die Sicherheitskonfiguration eher strikt sein. Für Anforderungen, die an Back-End-Enterprise-Bean-Server gerichtet sind,
kann die Sicherheitskonfiguration für abgehende Daten aus Gründen des Durchsatzes weniger
strikt ausfallen. Aufgrund dieser Flexibilität können Sie
eine Transportinfrastruktur entsprechend Ihren Anforderungen
entwerfen.
Nächste Schritte
Führen Sie nach Abschluss der Sicherheitskonfiguration die folgenden Schritte aus, um die Server zu speichern,
zu synchronisieren und neu zu starten:
- Klicken Sie in der Administrationskonsole auf Speichern, um alle an der Konfiguration vorgenommenen Änderungen
zu speichern.
Synchronisieren Sie die Konfiguration mit allen Node Agents.
- Stoppen Sie alle Server, und starten Sie sie erneut, sobald die Synchronisation abgeschlossen ist.