Inbound communications refers to the configuration
that determines the type of accepted authentication for inbound requests.
This authentication is advertised in the interoperable object reference
(IOR) that the client retrieves from the name server.
Procedure
- Start the administrative console.
- Click Security > Global security.
- Under RMI/IIOP security, click CSIv2 inbound communications.
- Consider the following layers of security:
- Identity assertion (attribute layer).
When selected, this server
accepts identity tokens from upstream servers. If the server receives
an identity token, the identity is taken from an originating client. For example,
the identity is in the same form that the originating client presented
to the first server. An upstream server sends the identity of the
originating client. The format of the identity can be either a principal
name, a distinguished name, or a certificate chain. In some cases,
the identity is anonymous. It is important to trust the upstream server
that sends the identity token because the identity authenticates on
this server. Trust of the upstream server is established either using
Secure Sockets Layer (SSL) client certificate authentication or basic
authentication. You must select one of the two layers of authentication
in both inbound and outbound authentication when you choose identity
assertion.
The server ID is sent
in the client authentication token with the identity token. The server
ID is checked against the trusted server ID list. If the server ID
is on the trusted server list, the server ID is authenticated. If
the server ID is valid, the identity token is put into a credential
and used for authorization of the request.
Note: If your configured registry is a Local OS, then the trust is instead established by checking
if the upstream server identity is authorized on the downstream server with UPDATE authority to the
CBIND class, profile CB.BIND.<optionalSAFProfilePrefix>.<cluster_short_name>. The
upstream server identity is sent using an SSL client certificate. If SSL is not used, the CBIND
check is performed against the started task identity of the upstream server.
Note: When identity assertion is enabled, message layer
or transport layer should be enabled also. For server-to-server communication,
besides enabling transport layer/client authentication, identity assertion,
or message layer should be enabled also.
For more information,
see Identity assertion.
- Message layer:
Basic authentication (GSSUP):
This type
of authentication is the most typical. The user ID and password or
authenticated token is sent from a pure client or from an upstream
server. When a user ID and password are received at the server, they
are authenticated with the user registry of the downstream server.
Lightweight
Third Party Authentication (LTPA):
In this case, an LTPA token
is sent from the upstream server. If you choose LTPA, then both servers
must share the same LTPA keys
Kerberos (KRB5):
To select
Kerberos, the active authentication mechanism must be Kerberos. In
this case, a Kerberos token is sent from the upstream server.
For
more information, read about Message layer authentication.
- Secure Sockets Layer client certificate authentication (transport
layer).
The SSL client certificate is used to authenticate instead
of using user ID and Password. If a server delegates an identity to
a downstream server, the identity comes from either the message layer
(a client authentication token) or the attribute layer (an identity
token), and not from the transport layer through the client certificate authentication.
A client has an SSL client certificate that
is stored in the keystore file of the client configuration. When SSL
client authentication is enabled on this server, the server requests
that the client send the SSL client certificate when the connection
is established. The certificate chain is available on the socket whenever
a request is sent to the server. The server request interceptor gets
the certificate chain from the socket and maps this certificate chain
to a user in the user registry. This type of authentication is optimal
for communicating directly from a client to a server. However, when
you must go downstream, the identity typically flows over the message
layer or through identity assertion.
A client has an SSL client certificate
that is stored in the key ring file of the client configuration. When
SSL client authentication is enabled on this server, the server requests
that the client send the SSL client certificate when the connection
is established. The certificate chain is available on the socket whenever
a request is sent to the server. The server request interceptor gets
the certificate chain from the socket and maps this certificate chain
to a user in the user registry. This type of authentication is optimal
for communicating directly from a client to a server. However, when
you have to go downstream, the identity typically flows over the message
layer or through identity assertion.
- Consider the following points when deciding what type of
authentication to accept:
- Configure
a trusted server list.
When identity assertion is selected for inbound requests, insert a pipe-separated (
|)
list of server administrator IDs to which this server can support identity token submission. For
backwards compatibility, you can still use a comma-delimited list. However, if the server ID is a
distinguished name (DN), then you must use a pipe-delimited (|) list because a comma delimiter does
not work. If you choose to support any server sending an identity token, you can enter an asterisk
(*) in this field. This action is called
presumed trust. In this case, use SSL client
certificate authentication between servers to establish the trust.
Supported configurations: This step applies if you are using
a Lightweight Directory Access Protocol (LDAP) or custom user registry. However, it does not apply
when you are using the local operating system user registry or a System Authorization Facility (SAF)
user registry.
- Configure
session management.
You can choose either stateful or stateless security.
Performance is optimum when choosing stateful sessions. The first
method request between a client and server is authenticated. All subsequent
requests (or until the credential token expires) reuse the session
information, including the credential. A client sends a context ID
for subsequent requests. The context ID is scoped to the connection
for uniqueness.
Results
When you finish configuring this panel, you have configured
most of the information that a client gathers when determining what
to send to this server. A client or server outbound configuration
with this server inbound configuration, determines the security that
is applied. When you know what clients send, the configuration is
simple. However, if you have a diverse set of clients with differing
security requirements, your server considers various layers of authentication.For
a Java Platform, Enterprise Edition application server, the authentication
choice is usually either identity assertion or message layer because
you want the identity of the originating client delegated downstream.
You cannot easily delegate a client certificate using an SSL connection. It
is acceptable to enable the transport layer because additional server
security, as the additional client certificate portion of the SSL
handshake, adds some overhead to the overall SSL connection establishment.
What to do next
After you determine which type of authentication data this
server might receive, you can determine what to select for outbound
security. For more information, see Configuring Common Secure Interoperability Version 2 outbound
authentication.