Einstellungen für abgehende CSIv2-Kommunikation

Verwenden Sie diese Seite, um die Funktionen festzulegen, die ein Server unterstützt, wenn er als Client für einen anderen Downstream-Server auftritt.

Führen Sie die folgenden Schritte aus, um diese Seite der Administrationskonsole anzuzeigen:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Klicken Sie unter "Authentifizierung" auf RMI/IIOP-Sicherheit > Abgehende CSIv2-Kommunikation.
Die Authentifizierungsfunktionen umfassen drei Authentifizierungsschichten, die parallel verwendet werden können:
Sicherheitsattribute weitergeben

Gibt an, dass die Weitergabe von Sicherheitsattributen während Anmeldeanforderungen unterstützt wird. Bei Auswahl dieser Option erhält der Anwendungsserver zusätzliche Informationen zur Anmeldeanforderung, z. B. die verwendete Authentifizierungsstärke, sowie zur Identität und Position des Anforderungssenders.

Wenn Sie diese Option nicht auswählen, akzeptiert der Anwendungsserver keine zusätzlichen Anmeldeinformationen für die Weitergabe an Downstream-Server.

Standardeinstellung Aktiviert
Wichtig: Wenn Sie den Replikationsservice verwenden, müssen Sie sicherstellen, dass die Option Sicherheitsattribute weitergeben aktiviert ist.
Anerkannte Server-ID verwenden

Gibt die Server-ID an, die der Anwendungsserver verwendet, um das Vertrauen zum Zielserver aufzubauen. Die Server-ID kann mit einer der folgenden Methoden gesendet werden:

  • Server-ID und Kennwort werden gesendet, wenn das Serverkennwort in der Registry-Konfiguration angegeben ist.
  • Es wird eine Server-ID in einem LTPA-Token (Lightweight Third Party Authentication), wenn die interne Server-ID verwendet wird.
Verwenden Sie für die Interoperabilität mit anderen Anwendungsservern als WebSphere Application Server eine der folgenden Methoden:
  • Konfigurieren Sie die Server-ID und das Kennwort in der Registry.
  • Wählen Sie die Option Anerkannte Server-ID verwenden aus, und geben Sie die anerkannte ID und das Kennwort so an, dass ein interoperables GSSUP-Token (Generic Security Services Username Password) anstelle eines LTPA-Token gesendet wird.
Standardeinstellung Inaktiviert
Alternative anerkannte ID angeben

Gibt einen alternativen Benutzer als anerkannte ID an, die anstelle der Server-ID an die Zielserver gesendet wird.

Diese Option wird für die Zusicherung der Identität empfohlen. Die ID wird automatisch anerkannt, wenn sie innerhalb derselben Zelle gesendet wird. Sie muss nicht in der Liste der anerkannten IDs in der Zelle enthalten sein. Diese ID muss jedoch in der Registry der Zielserver in einer externen Zelle und die Benutzer-ID in der Liste der anerkannten Identitäten enthalten sein. Andernfalls wird die ID während der Überprüfung der Vertrauensstellung zurückgewiesen.

Standardeinstellung Inaktiviert
Anerkannte Identität

Gibt die anerkannte Identität an, die vom sendenden an den empfangenden Server gesendet wird.

Wenn Sie in diesem Feld eine Identität angeben, kann diese in der Anzeige für das konfigurierte Benutzeraccount-Repository ausgewählt werden. Wenn Sie keine Identität angeben, wird ein LTPA-Toklen (Lightweight Third Party Authentication) zwischen den Servern gesendet.

[AIX Solaris HP-UX Linux Windows] [iSeries] Eine Liste (in der das Pipe-Zeichen (|) als Trennzeichen verwendet wird) mit den Benutzer-IDs der Serveradministratoren, die die Zusicherung der Identität für diesen Server durchführen dürfen. Beispiel: serverid1|serverid2|serverid3. Der Anwendungsserver unterstützt weiterhin das Komma (,) als Begrenzer in Listen, um die Abwärtskompatibilität zu gewährleisten. Der Anwendungsserver überprüft das Komma, falls mit dem Pipe-Zeichen (|) keine ID eines gültigen Servers gefunden wird.

[z/OS] Eine Liste (in der das Semikokon (;) oder das Komma als Trennzeichen verwendet wird) mit den IDs der Server, die die Zusicherung der Identität für diesen Server durchführen dürfen. Beispiel: serverid1;serverid2;serverid3 or serverid1,serverid2,serverid3.

Verwenden Sie diese Liste, um zu entscheiden, ob ein Server als vertrauenswürdig einzustufen ist. Auch wenn der Server in der Liste aufgeführt ist, muss der sendende Server sich noch am empfangenden Server authentifizieren, damit das Identitätstoken des sendenden Servers akzeptiert werden.

Kennwort

Gibt das Kennwort an, das der anerkannten Identität zugeordnet ist.

Datentyp Text
Kennwort bestätigen

Bestätigt das Kennwort, das der anerkannten Identität zugeordnet ist.

Datentyp Text
Authentifizierung auf Nachrichtenebene

Die folgenden Optionen sind für die Authentifizierung auf Nachrichtenebene verfügbar:
Nie
Gibt an, dass der Server keine Authentifizierung mit Benutzer-ID und Kennwort akzeptiert.
Unterstützt
Gibt an, dass Clients, die mit diesem Server kommunizieren, eine Benutzer-ID und ein Kennwort angeben können. Ohne diese Art der Authentifizierung muss jedoch unter Umständen eine Methode aufgerufen werden. Stattdessen kann beispielsweise eine anonyme Authentifizierung oder eine Authentifizierung mit Clientzertifikat verwendet werden.
Erforderlich
Gibt an, dass Clients, die mit diesem Server kommunizieren, für Methodenanforderungen eine Benutzer-ID und ein Kennwort angeben müssen.
Client/Server-Authentifizierung zulässig über:

Gibt an, dass die Client/Server-Authentifizierung über Kerberos, LTPA oder Basisauthentifizierung zulässig ist.

Die folgenden Optionen sind für die Authentifizierung von Clients beim Server verfügbar:
Kerberos (KRB5)
Wählen Sie diese Option aus, um Kerberos als Authentifizierungsverfahren anzugeben. Zuerst müssen Sie das Kerberos-Authentifizierungsverfahren konfigurieren. Weitere Informationen finden Sie im Artikel Kerberos über die Administrationskonsole als Authentifizierungsverfahren konfigurieren.
LTPA
Wählen Sie diese Option aus, um die LTPA-Tokenauthentifizierung (Lightweight Third-Party Authentication) zu konfigurieren und zu aktivieren.
Basisauthentifizierung
Die Basisauthentifizierung ist GSSUP (Generic Security Services Username Password). Bei diesem Authentifizierungsverfahren werden eine Benutzer-ID und ein Kennwort vom Client zur Authentifizierung an den Server gesendet.

Wenn Sie Basisauthentifizierung und LTPA auswählen und LTPA das aktive Authentifizierungsverfahren ist, akzeptiert der Server einen Downstream-Server über einen Benutzernamen, ein Kennwort oder ein LTPA-Token.

Wenn Sie Basisauthentifizierung und KRB5 auswählen und KRB5 das aktive Authentifizierungsverfahren ist, akzeptiert der Server einen Downstream-Server über einen Benutzernamen, ein Kennwort, ein Kerberos-Token oder ein LTPA-Token.

Wenn Sie Basisauthentifizierung nicht auswählen, akzeptiert der Server einen Downstream-Server nicht über einen Benutzernamen und ein Kennwort.

Transport

Gibt an, ob die Clientprozesse mit einem der für den Server konfigurierten Transportverfahren eine Verbindung zum Server herstellen.

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.

Anmerkung: Diese Option ist auf dem Betriebssystem z/OS nur verfügbar, wenn Knoten der Version 6.0.x und früherer Versionen in der Zelle vorhanden sind.
TCP/IP
Wenn Sie TCP/IP auswählen, öffnet der Server nur einen TCP/IP-Listener-Port. Alle eingehenden Anforderungen haben keinen SSL-Schutz.
SSL erforderlich
Wenn Sie SSL erforderlich auswählen, öffnet der Server nur einen SSL-Listener-Port, und alle eingehenden Anforderungen werden mit SSL empfangen.
SSL unterstützt
Wenn Sie SSL unterstützt auswählen, öffnet der Server einen TCP/IP- und einen SSL-Listener-Port, und die meisten eingehenden Anforderungen werden mit SSL empfangen.
Geben Sie eine feste Portnummer für die folgenden Ports an. Die Portnummer null zeigt an, dass zur Laufzeit eine dynamische Zuordnung vorgenommen wird. [AIX Solaris HP-UX Linux Windows] [iSeries]

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

[z/OS]

ORB_SSL_LISTENER_ADDRESS

Standardeinstellung SSL unterstützt
Einstellmöglichkeiten TCP/IP, SSL erforderlich, SSL unterstützt
SSL-Einstellungen

Gibt eine Liste von vordefinierten SSL-Einstellungen für eingehende Verbindungen an.

[z/OS] Anmerkung: Diese Option ist auf dem Betriebssystem z/OS nur verfügbar, wenn Knoten der Version 6.0.x und früherer Versionen in der Zelle vorhanden sind.
Datentyp String
[AIX Solaris HP-UX Linux Windows] [iSeries] Standardeinstellung DefaultSSLSettings
[z/OS] Standardeinstellung DefaultIIOPSSL
Einstellmöglichkeiten Alle SSL-Einstellungen, die im SSL-Konfigurationsrepertoire konfiguriert wurden.
Authentifizierung mit Clientzertifikat

Gibt an, ob ein Clientzertifikat aus der konfigurierten Keystore-Datei verwendet wird, um die Authentifizierung für den Server durchzuführen, wenn die SSL-Verbindung zwischen diesem Server und einem Downstream-Server hergestellt wird, vorausgesetzt, der Downstream-Server unterstützt die Authentifizierung über Clientzertifikate.

Die Verwendung der Authentifizierung mit Clientzertifikaten bietet in der Regel eine höhere Leistung als die Authentifizierung auf Nachrichtenebene, erfordert aber einige zusätzliche Konfigurationsschritte. Sie müssen z. B. sicherstellen, dass dieser Server ein persönliches Zertifikat und der Downstream-Server das Ausstellerzertifikat dieses Servers besitzt.

Wenn Sie die Authentifizierung mit Clientzertifikaten auswählen, stehen die folgenden Optionen zur Verfügung:
Nie
Gibt an, dass der Server keine SSL-Authentifizierung mit Clientzertifikaten mit Downstream-Servern durchführt.
Unterstützt
Gibt an, dass der Server SSL-Clientzertifikate für die Authentifizierung bei Downstream-Servern verwenden kann. Ohne diese Art der Authentifizierung kann jedoch unter Umständen eine Methode aufgerufen werden. Beispielsweise kann der Server eine anonyme Authentifizierung oder eine Basisauthentifizierung durchführen.
Erforderlich
Gibt an, dass der Server SSL-Clientzertifikate für die Authentifizierung bei Downstream-Servern verwenden muss.
Standardeinstellung Aktiviert
Anmeldekonfiguration

Gibt den Typ von Systemanmeldekonfiguration an, der für die Authentifizierung eingehender Anforderungen verwendet wird.

Wenn Sie angepasste Anmeldemodule hinzufügen möchten, klicken Sie auf Sicherheit > Globale Sicherheit. Klicken Sie unter "Authentifizierung" auf Java Authentication and Authorization Service > Systemanmeldungen.

Stateful-Sitzungen

Wählen Sie diese Option aus, um Stateful-Sitzungen zu aktivieren, die meist zur Leistungsverbesserung verwendet werden.

Beim ersten Kontakt zwischen einem Client und einem Server muss eine vollständige Authentifizierung durchgeführt werden. Alle nachfolgenden Kontakte mit gültigen Sitzungen verwenden jedoch die Sicherheitsinformationen erneut. Der Client übergibt eine Kontext-ID an den Server, und die ID wird zum Lokalisieren der Sitzung verwendet. Die Kontext-ID wird der Verbindung zugeordnet, wodurch die Verbindung eine eindeutige Kennung erhält. Wenn die Sicherheitssitzung ungültig und die Option für die Wiederholung der Authentifizierung aktiviert ist (Standardeinstellung), macht der clientseitige Sicherheits-Interceptor die clientseitige Sitzung ungültig und übergibt die Anforderung transparent erneut. Eine solche Situation kann eintreten, wenn die Sitzung nicht auf dem Server vorhanden ist, z. B., wenn der Server ausgefallen ist und den Betrieb wieder aufnimmt. Ist dieser Wert inaktiviert, müssen alle Methodenaufrufe erneut authentifiziert werden.

Grenzwert für CSIv2-Sitzungscache aktivieren

Gibt an, ob die Größe des CSIv2-Sitzungscaches begrenzt werden soll.

Wenn Sie diese Option aktivieren, müssen Sie Werte für die Optionen Maximale Cachegröße und Zeitlimit für inaktive Sitzungen festlegen. Wenn Sie diese Option nicht aktivieren, wird der CSIv2-Sitzungscache nicht begrenzt.

In den früheren Versionen des Anwendungsservers haben Sie diesen Wert möglicherweise mit der angepassten Eigenschaft "com.ibm.websphere.security.util.csiv2SessionCacheLimitEnabled" festgelegt. In dieser Produktversion empfiehlt es sich, den Wert in dieser Anzeige der Administrationskonsole und nicht als angepasste Eigenschaft zu definieren.

Standardeinstellung false
Maximale Cachegröße

Geben Sie die maximale Größe des Sitzungscaches an, bei deren Erreichen abgelaufene Sitzungen aus dem Cache gelöscht werden.

Abgelaufene Sitzungen sind laut Definition Sitzungen, deren Inaktivitätszeit den Wert überschreitet, der im Feld Zeitlimit für inaktive Sitzungen angegeben wurde. Wenn Sie einen Wert für das Feld Maximale Cachegröße angeben, sollten Sie einen Wert zwischen 100 und 1000 (Einträge) wählen.

Ziehen Sie die Definition eines Wertes für dieses Feld in Erwägung, wenn Ihre Umgebung die Kerberos-Authentifizierung verwendet und eine geringe Zeitabweichung für das konfigurierte Key Distribution Center (KDC) aufweist. In diesem Szenario ist eine geringe Zeitabweichung laut Definition eine Zeitabweichung von weniger als 20 Minuten. Erhöhen Sie den Wert dieses Felds, wenn die kleine Cachegröße bewirkt, dass die Garbage-Collection so häufig durchgeführt wird, dass sie sich auf die Leistung des Anwendungsservers auswirkt.

In den früheren Versionen des Anwendungsservers haben Sie diesen Wert möglicherweise mit der angepassten Eigenschaft "com.ibm.websphere.security.util.csiv2SessionCacheMaxSize" festgelegt. In dieser Produktversion empfiehlt es sich, den Wert in dieser Anzeige der Administrationskonsole und nicht als angepasste Eigenschaft zu definieren.

Dieses Feld gilt nur, wenn Sie die Option Statusabhängige Sitzungen und die Option Grenzwert für CSIv2-Sitzungscache aktivieren auswählen.

Standardeinstellung Standardmäßig wird kein Wert gesetzt.
Einstellmöglichkeiten 100 bis 1000 Einträge
Zeitlimit für inaktive Sitzungen

Diese Eigenschaft gibt an, wie lange (in Millisekunden) eine CSIv2-Sitzung inaktiv bleiben darf, bevor sie gelöscht wird. Die Sitzung wird gelöscht, wenn Sie die Option Grenzwert für CSIv2-Sitzungscache auswählen und der im Feld Maximale Cachegröße festgelegte Wert überschritten wird.

Das Zeitlimit gilt nur, wenn Sie die Option Statusabhängige Sitzungen und die Option Grenzwert für CSIv2-Sitzungscache aktivieren auswählen. Legen Sie einen kleineren Wert in diesem Feld fest, wenn Ihre Umgebung die Kerberos-Authentifizierung verwendet und eine geringe Zeitabweichung für das konfigurierte Key Distribution Center (KDC) aufweist. In diesem Szenario ist eine geringe Zeitabweichung laut Definition eine Zeitabweichung von weniger als 20 Minuten. Eine geringe Zeitabweichung kann zu einer höheren Anzahl zurückgewiesener CSIv2-Sitzungen führen. Mit einem kleineren Wert für das Feld Zeitlimit für inaktive Sitzungen kann der Anwendungsserver diese zurückgewiesenen Sitzungen jedoch häufiger bereinigen und damit unter Umständen Ressourcenengpässe reduzieren.

In den früheren Versionen von WebSphere Application Server haben Sie diesen Wert möglicherweise mit der angepassten Eigenschaft "com.ibm.websphere.security.util.csiv2SessionCacheIdleTime" festgelegt. In dieser Produktversion empfiehlt es sich, den Wert in dieser Anzeige der Administrationskonsole und nicht als angepasste Eigenschaft zu definieren. Wenn Sie den Wert zuvor als angepasste Eigenschaft definiert haben, wurde der Wert in Millisekunden angegeben und in dieser Anzeige der Administrationskonsole in Sekunden konvertiert. In dieser Anzeige der Administrationskonsole müssen Sie den Wert in Sekunden angeben.

Standardeinstellung Standardmäßig wird kein Wert gesetzt.
Einstellmöglichkeiten 60 bis 86.400 Sekunden
Angepasste Zuordnung abgehender Anforderungen

Aktiviert die Verwendung angepasster Anmeldemodule für abgehende RMI-Anforderungen (Remote Method Invocation).

Das angepasste Anmeldemodul filtert oder führt vor dem Absetzen des vordefinierten abgehenden RMI-Aufruf andere Funktionen aus.

Führen Sie zum Deklarieren einer angepassten abgehenden Zuordnung die folgenden Schritte aus:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. Klicken Sie unter "Authentifizierung" auf Java Authentication and Authorization Service > Systemanmeldungen > Neu.
Anerkannte Authentifizierungs-Realms - abgehend

Wenn eine Realm-übergreifende RMI/IIOP-Kommunikation stattfindet, verwenden Sie diesen Link, um abgehende anerkannte Realms hinzuzufügen.

Die Berechtigungsnachweistoken werden nur an die anerkannten Realms gesendet. Außerdem muss der empfangende Server diesen Realm in der Konfiguration der eingehenden anerkannten Realms anerkennen, um das LTPA-Token zu validieren.




Mit (online) gekennzeichnete Links setzen einen Internet-Zugang voraus.

Zugehörige Tasks


Dateiname: usec_outbound.html