Use this page to specify the features that a server supports
when acting as a client to another downstream server.
To view this administrative console page, complete
the following steps:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, click RMI/IIOP security > CSIv2 outbound
authentication.
You also can view this administrative console
page by completing the following steps:
- Click Servers > Application Servers > server_name.
- Under Security, click Server security.
- Click CSIv2 outbound authentication.
Authentication features include the following layers of authentication
that you can use simultaneously:
- Transport layer
- The transport layer, the lowest layer, might contain a Secure
Sockets Layer (SSL) client certificate as the identity.
- Attribute layer
- The attribute layer might contain an identity token, which is
an identity from an upstream server that is already authenticated.
The attribute layer has the highest priority, followed by the message
layer and then the transport layer. If this server sends all three
- the attribute layer, the message layer, and the transport layer
- only the attribute layer is used by the downstream server. The only
way to use the SSL client certificate as the identity is if it is
the only information presented during the outbound request.
Configuration tab
Client certificate authentication
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.
If you select client certificate authentication, the following
options are available:
- Never
- This option indicates that this server does not attempt Secure
Sockets Layer (SSL) client certificate authentication with downstream
servers.
- Supported
- This option indicates that this server can use SSL client certificates
to authenticate to downstream servers. However, a method can be invoked
without this type of authentication. For example, the server can use
anonymous or basic authentication instead.
- Required
- This option indicates that this server must use SSL client certificates
to authenticate to downstream servers.
Identity assertion
Specifies whether to assert identities from one server
to another during a downstream enterprise bean invocation.
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.
- Use server trusted identity
- Specifies the server identity that the application server uses
to establish trust with the target server. The server identity can
be sent using one of the following methods:
- A server ID and password when the server password is specified
in the registry configuration.
- A server ID in a Lightweight Third Party Authentication (LTPA)
token when the internal server ID is used.
For interoperability with application servers other than WebSphere
Application Server, use one of the following methods:
- Configure the server ID and password in the registry.
- Select the Specify an alternative trusted identity option
and specify the trusted identity and password so that an interoperable
Generic Security Services Username Password (GSSUP) token is sent
instead of an LTPA token.
- Specify an alternative trusted identity
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.
- Trusted identity
- Specifies the trusted identity that is sent from the sending server
to the receiving server.
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.
- Password
- Specifies the password that is associated with the trusted identity.
- Confirm password
- Confirms the password that is associated with the trusted identity.
Stateful sessions
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.
Login configuration
Specifies the type of system login configuration that is
used for outbound authentication.
You can add custom login modules before or after
this login module by completing the following steps:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, click Java Authentication and Authorization
Service > System logins > New.
Custom outbound mapping
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.
To declare a custom outbound mapping, complete
the following steps:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, click Java Authentication and Authorization
Service > System logins > New.
Security attribute propagation
Enables the application server to propagate the Subject
and the security content token to other application servers using
the Remote Method Invocation (RMI) protocol.
Verify that you are using Lightweight Third Party Authentication
(LTPA) as your authentication mechanism. LTPA is the only authentication
mechanism that is supported when you enable the security attribute
propagation feature. To configure LTPA, complete the following steps:
- Click Security > Secure administration, applications, and infrastructure.
- Under Authentication, click Authentication mechanisms and expiration.
By default, the Security attribute
propagation option is enabled and outbound login configuration is
invoked. If you clear this option, the application server does not
propagate any additional login information to downstream servers.
If you select the
Use SWAM-no authenticated communication between
servers option on the Authentication mechanisms and expiration
panel, the security attribute propagation feature is not supported.
Note: SWAM is deprecated in the application
server Version 6.1 and will
be removed in a future release.
Important: When
you use the replication services, ensure that security attribute propagation
is enabled. Security attribute propagation is enabled, by default.
Trusted target realms
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.