Einstellungen für eingehende CSIv2-Kommunikation

Verwenden Sie diese Seite, um die Funktionen anzugeben, die ein Server für einen Client, der auf die Serverressourcen zugreift, unterstützen soll.

Gehen Sie zum Anzeigen dieser Seite der Administrationskonsole wie folgt vor:

Klicken Sie auf Sicherheit > Globale Sicherheit.
Klicken Sie unter "Authentifizierung" auf RMI/IIOP-Sicherheit > Eingehende CSIv2-Kommunikation.

Verwenden Sie die Einstellungen für die eingehende CSI-Kommunikation, um den Typ der Authentifizierungsdaten zu konfigurieren, die in einer eingehenden Anforderung oder in einem eingehenden Transport enthalten sind.

Die Authentifizierungsfunktionen umfassen drei Authentifizierungsschichten, die parallel verwendet werden können:

CSIv2-Attributebene. Die Attributschicht kann ein Identitätstoken enthalten, das eine Identität von einem Upstream-Server darstellt und bereits authentifiziert ist. Die Identitätsschicht hat die höchste Priorität, gefolgt von der Nachrichtenschicht und schließlich der Transportschicht. Wenn ein Client Daten über alle drei Schichten sendet, wird nur die Identitätsschicht verwendet. Das SSL-Clientzertifikat kann nur als Identität verwendet werden, wenn es die einzige Information ist, die während der Anforderung bereitgestellt wird. Der Client ruft die IOR (Interoperable Object Reference) aus dem Namespace ab und liest die Werte der markierten Komponente, um festzustellen, welche Sicherheitsmaßnahmen der Server benötigt.
CSIv2-Transportebene. Die Transportschicht, die die niedrigste Schicht ist, kann ein SSL-Clientzertifikat (Secure Sockets Layer) als Identität enthalten.
CSIv2-Nachrichtenebene. Die Nachrichtenschicht kann eine Benutzer-ID und ein Kennwort oder ein authentifiziertes Token mit Verfallsdatum enthalten.

Sicherheitsattribute weitergeben

Gibt die Unterstützung für die Weitergabe von Sicherheitsattributen während Anmeldeanforderungen an. 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.

Information	Wert
Standardeinstellung	Aktiviert

Wichtig: Wenn Sie den Replikationsservice verwenden, müssen Sie sicherstellen, dass die Option Sicherheitsattribute weitergeben aktiviert ist.

Zusicherung der Identität verwenden

Gibt an, dass die Identitätszusicherung eine Methode ist, beim Downstream-Aufruf einer EJB (Enterprise JavaBeans) die Identitäten zwischen Servern zuzusichern.

Der Server führt keine erneute Authentifizierung der zugesicherten Identität durch, weil er dem Upstream-Server vertraut. Die Zusicherung der Identität hat Vorrang vor allen anderen Arten der Authentifizierung.

Die Zusicherung der Identität wird in der Attributschicht ausgeführt und kann nur auf Servern durchgeführt werden. Der Principal, der auf dem Server ermittelt wird, ist von Prioritätsregeln abhängig. Wenn die Zusicherung der Identität verwendet wird, wird die Identität immer aus der Attributschicht abgeleitet. Wenn die Basisauthentifizierung ohne die Identitätszusicherung verwendet wird, wird die Identität immer von der Nachrichtenebene abgeleitet. Wenn schließlich die Authentifizierung über SSL-Clientzertifikate ohne Basisauthentifizierung oder Identitätszusicherung durchgeführt wird, wird die Identität von der Transportschicht abgeleitet.

Die zugesicherte Identität stellt die Aufrufberechtigung dar, die durch den RunAs-Modus für die Enterprise-Bean festgelegt wird. Ist der RunAs-Modus Client, stimmt die Identität mit der Clientidentität überein. Ist der RunAs-Modus System, stimmt die Identität mit der Serveridentität überein. Ist der RunAs-Modus Angegeben, entspricht die Identität der angegebenen Identität. Der empfangende Server empfängt die Identität in einem Identitätstoken und empfängt auch die Identität des sendenden Servers in einem Clientauthentifizierungstoken. Der empfangende Server prüft im Eintragsfeld IDs vertrauenswürdiger Server, ob die Identität des sendenden Servers vertrauenswürdig ist. Geben Sie eine Liste von Principal-Namen ein. Verwenden Sie Pipezeichen als Trennzeichen. Beispiel: serverid1|serverid2|serverid3.

Alle Identitätstokentypen werden dem Feld für die Benutzer-ID der aktiven Benutzerregistry zugeordnet. Das Identitätstoken ITTPrincipal wird den Feldern für die Benutzer-IDs eins zu eins zugeordnet. Beim Identitätstoken ITTDistinguishedName wird der Wert des ersten Gleichheitszeichens dem Feld für die Benutzer-ID zugeordnet. Beim Identitätstoken ITTCertChain wird der Wert des ersten Gleichheitszeichens des definierten Namens dem Feld für die Benutzer-ID zugeordnet.

Wird eine Authentifizierung für eine LDAP-Benutzerregistry durchgeführt, legen die LDAP-Filter fest, wie Identitäten der Typen ITTCertChain und ITTDistinguishedName der Registry zugeordnet werden. Wenn der Tokentyp ITTPrincipal ist, wird der Principal dem Feld "UID" in der LDAP-Registry zugeordnet.

Information	Wert
Standardeinstellung	Inaktiviert

Die folgende Option ist aktiviert, wenn die aktive Benutzerregistry eine Benutzerregistry des lokalen Betriebssystems (LocalOS) ist, Ihre z/OS-Sicherheitsversion die Zuordnung verteilter Identitäten unterstützt und keine Knoten vor WebSphere Application Server Version 8.0 vorhanden sind:

Zertifikat und DN über verteilte SAF-Identitätszuordnung zuordnen: Wenn Sie diese Option auswählen, wird ein zugesichertes Zertifikat und einen definierten Namen über einen RACMAP-Filter einer SAF-Benutzeridentität zugeordnet.
Standardmäßig ist diese Option nicht ausgewählt. Wenn diese Option ausgewählt wird, wird die angepasste Sicherheitseigenschaft "com.ibm.websphere.security.certdn.useRACMAPMappingToSAF" auf true gesetzt.

Anmerkung: Diese Option ist nur sichtbar, wenn die aktive Registry "LocalOS" (Lokales Betriebssystem) ist, die Zelle keine heterogene Zelle ist (keine Knoten vor WebSphere Application Server Version 8.0 enthält) und das z/OS-Sicherheitsprodukt die Zuordnung von SAF-Identitäten unterstützt (d. h. für RACF z/OS Version 1.11 oder höher).

Anmerkung: Wenn Ihr definierter Name ein Leerzeichen zwischen den Attributen enthält, müssen Sie RACF-APAR OA34258 oder PTF UA59873 und SAF-APAR OA34259 oder PTF UA59871 anwenden, damit die Leerzeichen ordnungsgemäß geparst werden.

Anerkannte Identitäten

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

Eine Liste (in der das Pipezeichen (|) 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 Pipezeichen (|) keine ID eines gültigen Servers gefunden wird.

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

Information	Wert
Datentyp	String

Authentifizierung mit Clientzertifikat

Gibt an, dass die Authentifizierung durchgeführt wird, wenn die ursprüngliche Verbindung zwischen dem Client und dem Server während einer Methodenanforderung hergestellt wird.

In der Transportschicht wird die SSL-Clientauthentifizierung (Secure Sockets Layer) durchgeführt. Auf der Nachrichtebene wird die Basisauthentifizierung (Benutzer-ID/Kennwort) verwendet. Die Authentifizierung über Clientzertifikat lässt sich normalerweise besser durchführen als die Authentifizierung über die Nachrichtenebene, erfordert jedoch einige zusätzliche Konfigurationsschritte. Beispielsweise muss sichergestellt werden, dass der Server das Ausstellerzertifikat jedes Clients anerkennt, der eine Verbindung zum Server herstellt. Wenn der Client eine Zertifizierungsstelle (Certificate Authority, CA) verwendet, um sein persönliches Zertifikat zu erstellen, benötigen Sie nur das Basiszertifikat der Zertifizierungsstelle, die sich im Ausstellerabschnitt der SSL-Trustdatei des Servers befindet.

[AIX Solaris HP-UX Linux Windows] [IBM i] Wenn das Zertifikat anhand einer LDAP-Benutzerregistry (Lightweight Directory Access Protocol) authentifiziert wird, wird der definierte Name (DN) auf der Basis des bei der Konfiguration von LDAP definierten Filters zugeordnet. Wenn das Zertifikat für eine LocalOS-Benutzerregistry authentifiziert wird, wird das erste Attribut des definierten Namens (DN) im Zertifikat, normalerweise der allgemeine Name (CN), der Benutzer-ID in der Registry zugeordnet.

[z/OS] Wenn das Zertifikat für eine LocalOS-Benutzerregistry authentifiziert wird, wird das Zertifikat der Benutzer-ID in der Registry zugeordnet.

Die Identifizierung über Clientzertifikate wird nur durchgeführt, wenn keine Informationen einer anderen Authentifizierungsschicht an den Server übergeben werden.

Nie: Gibt an, dass Clients keine Authentifizierung mit SSL-Clientzertifikaten mit diesem Server durchführen.
Unterstützt: Gibt an, dass Clients, die eine Verbindung zu diesem Server herstellen, eine Authentifizierung mit SSL-Clientzertifikaten durchführen können. Der Server kann jedoch eine Methode ohne diese Art der Authentifizierung aufrufen. Stattdessen kann beispielsweise eine anonyme Authentifizierung oder eine Basisauthentifizierung verwendet werden.
Anmerkung: Wenn für "Authentifizierung eingehender CSIv2-Transporte" auf dem Server der Wert "Unterstützt" eingestellt ist, wird das Clientzertifikat für die Authentifizierung verwendet.
Erforderlich: Gibt an, dass Clients, die eine Verbindung zu diesem Server herstellen, vor dem Aufruf der Methode eine Authentifizierung mit SSL-Clientzertifikaten durchführen müssen.

Zertifikat über verteilte SAF-Identitätszuordnung zuordnen: Wenn Sie diese Option auswählen, wird ein auf der CSIv2-Transportschicht empfangenes Zertifikat über einen RACMAP-Filter einer SAF-Benutzeridentität zugeordnet.
Standardmäßig ist diese Option nicht ausgewählt. Wenn diese Option ausgewählt wird, wird die angepasste Sicherheitseigenschaft "com.ibm.websphere.security.certificate.useRACMAPMappingToSAF" auf true gesetzt.

Anmerkung: Diese Option ist nur sichtbar, wenn die aktive Registry "LocalOS" (Lokales Betriebssystem) ist, die Zelle keine heterogene Zelle ist (keine Knoten vor WebSphere Application Server Version 8.0 enthält) und das z/OS-Sicherheitsprodukt die Zuordnung von SAF-Identitäten unterstützt (d. h. für RACF z/OS Version 1.11 oder höher).

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 der Plattform z/OS nur verfügbar, wenn Knoten der Version 6.1 und Knoten 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. Keine der eingehenden Anforderungen hat 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]

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

ORB_SSL_LISTENER_ADDRESS

Information	Wert
Standardeinstellung	SSL erforderlich
Einstellmöglichkeiten	TCP/IP, SSL erforderlich, SSL unterstützt

SSL-Einstellungen

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

Anmerkung: Diese Option ist auf der Plattform z/OS nur verfügbar, wenn Knoten der Version 6.1 und Knoten früherer Versionen in der Zelle vorhanden sind.

Information	Wert
Datentyp	String
Standardeinstellung	DefaultSSLSettings
Standardeinstellung	DefaultIIOPSSL
Einstellmöglichkeiten	Alle SSL-Einstellungen, die im SSL-Konfigurationsrepertoire konfiguriert wurden.

Authentifizierung auf Nachrichtenebene

Die folgenden Optionen sind für die Authentifizierung auf Nachrichtenebene verfügbar:

Nie: Gibt an, dass der Server keine Authentifizierung mit einem der ausgewählten Verfahren akzeptiert.
Unterstützt: Gibt an, dass sich ein Client, der mit diesem Server kommuniziert, über einen der unten ausgewählten Mechanismen authentifizieren kann. 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 Authentifizierungsinformationen mit einem der unten ausgewählten Mechanismen 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 anzugeben.
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, werden ein Benutzername, ein Kennwort und LTPA-Token akzeptiert.

Wenn Sie Basisauthentifizierung und KRB5 auswählen und KRB5 das aktive Authentifizierungsverfahren ist, werden ein Benutzername, ein Kennwort, Kerberos-Token und LTPA-Token akzeptiert.

Wenn Sie Basisauthentifizierung nicht auswählen, werden kein Benutzername und kein Kennwort vom Server akzeptiert.

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. Wenn diese Option inaktiviert ist, muss bei jedem Methodenaufruf eine neue Authentifizierung erfolgen.

Information	Wert
Standardeinstellung	Aktiviert

Anerkannte Authentifizierungsrealms - eingehend

Wählen Sie diesen Link aus, um die Anerkennung eingehender Daten für Realms zu konfigurieren. Die Einstellungen für eingehende Authentifizierungsrealms sind nicht spezifisch für CSIv2. Sie können auch konfigurieren, von welchen Realms eingehende Daten für mehrere Sicherheitsdomänen anerkannt werden.

Der Begriff "Eingehende Authentifizierung" bezieht sich auf die Konfiguration, die festlegt, welche Art der Authentifizierung für eingehende Anforderungen akzeptiert wird. Diese Authentifizierung wird in der Internet Object Reference (IOR) empfohlen, die der Client aus dem Servernamen abruft.

Dateiname: usec_inbound.html