Use this page to specify the features that a server supports when acting as a client to another downstream server.
Specifies whether a client certificate from the configured keystore is used to authenticate to the server when the SSL connection is made between this server and a downstream server, provided that the downstream server supports client certificate authentication.
Typically, client certificate authentication has a higher performance than message layer authentication, but requires some additional setup. These additional steps include verifying that this server has a personal certificate and that the downstream server has the signer certificate of this server.
Specifies whether to assert identities from one server to another during a downstream enterprise bean invocation.
The identity asserted is the invocation
credential that is determined by the RunAs mode for the enterprise
bean. If the RunAs mode is Client, the identity is the client identity.
If the RunAs mode is System, the identity is the server identity.
If the RunAs mode is Specified, the identity is the identity specified.
The receiving server receives the identity in an identity token and
also receives the sending server identity in a client authentication
token. The receiving server validates the identity of the sending
server to ensure a trusted identity.
The identity
asserted is the client identity. If there are multiple identity types
to assert, the identity is asserted in the following order: client
certificate, distinguished name (DN), System Authorization Facility
(SAF) user ID. The receiving server receives the identity in an identity
token with an empty client authentication token. The Secure Sockets
Layer (SSL) certificate of the server acts as the identity of the
server to the receiving server.
When specifying identity assertion on the
CSIv2 authentication outbound panel, you must also select basic authentication
as supported or required on the CSIv2 authentication inbound panel.
The server identity can then be submitted with the identity token,
so that the receiving server can trust the sending server.
Without specifying basic authentication as supported or required,
trust is not established and the identity assertion fails.
Specifies an alternative user as the trusted identity that is sent to the target servers instead of sending the server identity. This option is recommended for identity assertion. The identity is automatically trusted when it is sent within the same cell and does not need to be in the trusted identities list within the same cell. However, this identity must be in the registry of the target servers in an external cell and the user ID must be on the trusted identities list or the identity is rejected during trust evaluation.
If you specify an identity in this field, it can be selected on the panel for your configured user account repository. If you do not specify an identity, a Lightweight Third Party Authentication (LTPA) token is sent between the servers.
Specifies whether to reuse security information during authentication. This option is usually used to increase performance.
On z/OS
systems, this option is ignored. The sending server prefers stateful
sessions and uses them if the receiving server supports it.
The first contact between a client and
server must fully authenticate. However, all subsequent contacts with
valid sessions reuse the security information. The client passes a
context ID to the server, and that ID is used to look up the session.
The context ID is scoped to the connection, which guarantees uniqueness.
When the security session is not valid and if authentication retry
is enabled, which is the default, the client-side security interceptor
invalidates the client-side session and resubmits the request transparently.
For example, if the session does not exist on the server; the server
fails and resumes operation.
When this value is disabled, every method
invocation must authenticate again.
Specifies the type of system login configuration that is used for outbound authentication.
Enables the use of custom Remote Method Invocation (RMI) outbound login modules.
The custom login module maps or performs other functions before the predefined RMI outbound call.
Enables the application server to propagate the Subject and the security content token to other application servers using the Remote Method Invocation (RMI) protocol.
Specifies a list of trusted target realms, separated by a pipe character (|), that differ from the current realm.
Prior to WebSphere Application Server, Version 5.1.1, if the current realm does not match the target realm, the authentication request is not sent outbound to other application servers.