Verwenden Sie diese Seite, um die Funktionen festzulegen, die ein Server unterstützt, wenn er als Client für einen anderen Downstream-Server auftritt.
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 |
Gibt an, dass die Identitätszusicherung eine Methode ist, beim Downstream-Aufruf einer EJB 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 auf der Attributebene 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 durchgeführt wird, wird die Identität immer aus der Attributebene 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 Transportebene 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 Eingabefeld Anerkannte Server-IDs, ob die Identität des sendenden Servers vertrauenswürdig ist. Geben Sie eine Liste von Principal-Namen ein. Verwenden Sie Pipe-Zeichen als Trennzeichen. Beispiel: serverid1|serverid2|serverid3.
Alle Identitätstokentypen werden dem Feld für die Benutzer-ID der aktiven Benutzer-Registry 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-Benutzer-Registry 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.
Standardeinstellung | Inaktiviert |
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:
Standardeinstellung | Inaktiviert |
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 |
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.
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.
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.
Gibt das Kennwort an, das der anerkannten Identität zugeordnet ist.
Datentyp | Text |
Bestätigt das Kennwort, das der anerkannten Identität zugeordnet ist.
Datentyp | Text |
Gibt an, dass die Client/Server-Authentifizierung über Kerberos, LTPA oder Basisauthentifizierung zulässig ist.
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.
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.
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS
ORB_SSL_LISTENER_ADDRESS
Standardeinstellung | SSL unterstützt |
Einstellmöglichkeiten | TCP/IP, SSL erforderlich, SSL unterstützt |
Gibt eine Liste von vordefinierten SSL-Einstellungen für eingehende Verbindungen an.
Datentyp | String |
![]() ![]() |
DefaultSSLSettings |
![]() |
DefaultIIOPSSL |
Einstellmöglichkeiten | Alle SSL-Einstellungen, die im SSL-Konfigurationsrepertoire konfiguriert wurden. |
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.
Standardeinstellung | Aktiviert |
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.
Wählen Sie diese Option aus, um statusabhängige 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.
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.
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.