Set CSIv2 inbound communications

 

+

Search Tips   |   Advanced Search

 

To configure CSIv2 inbound communications, from the console...

Security | Global security | RMI/IIOP security | CSIv2 inbound communications

The type of accepted authentication for inbound requests is advertised in the IOR the client retrieves from the name server.

CSIv2 Attribute Layer

When selected, the appserver accepts identity tokens from upstream appservers.

The format of the identity can be either...

• principal name
• distinguished name
• certificate chain

In some cases, the identity is anonymous. It is important to trust the upstream appserver that sends the identity token because the identity authenticates on this appserver. Trust of the upstream appserver is established either using client certificate authentication or basic authentication. Select one of the two layers of authentication in both inbound and outbound authentication when you choose identity assertion.

1. The appserver ID is sent in the client authentication token with the identity token.

2. The appserver ID is checked against the trusted appserver ID list.

3. If the appserver ID is on the trusted appserver list, the appserver ID is authenticated.

4. If the appserver ID is valid, the identity token is put into a credential and used for authorization of the request.

CSIv2 Message Layer

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 appserver. When a user ID and password are received at the appserver, they are authenticated with the user registry.

Usually, a token is sent from an upstream appserver and a user ID and password are sent from a client, including a servlet. When a token is received at the appserver level, the token is validated to determine whether tampering has occurred or whether it is expired.

z/OS does not support a user ID or password from a appserver acting as a client.

CSIv2 Transport Layer

The SSL client certificate is used to authenticate instead of using user ID and Password. If a appserver delegates an identity to a downstream appserver, 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 appserver, the appserver 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 appserver. The appserver 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 appserver. However, when we have to go downstream, the identity typically flows over the message layer or through identity assertion.

A appserver can receive multiple layers simultaneously, so an order of precedence rule decides which identity to use. The identity assertion layer has the highest priority, the message layer follows, and the transport layer has the lowest priority. The client certificate authentication is used when it is the only layer provided. If the message layer and the transport layer are provided, the message layer is used to establish the identity for authorization. The identity assertion layer is used to establish precedence when provided.

Does this appserver usually receive requests from a client, from a appserver, or both? If the appserver always receives requests from a client, identity assertion is not needed. We can choose either the message layer, the transport layer, or both. We also can decide when authentication is required or just supported. To select a layer as required, the sending client must supply this layer, or the request is rejected. However, if the layer is only supported, the layer might not be supplied.

What kind of client identity is supplied? If the client identity is client certificates authentication and you want the certificate chain to flow downstream so that it maps to the downstream appserver user registries, identity assertion is the appropriate choice. Identity assertion preserves the format of the originating client. If the originating client authenticated with a user ID and password, a principal identity is sent. If authentication is done with a certificate, the certificate chain is sent.

In some cases, if the client authenticated with a token and a LDAP appserver is the user registry, then a distinguished name (DN) is sent.

Set a trusted appserver list.

When identity assertion is selected for inbound requests, insert a pipe-separated (|) list of appserver administrator IDs to which this appserver can support identity token submission. For backwards compatibility, we can still use a comma-delimited list. However, if the appserver ID is a distinguished name (DN), then use a pipe-delimited (|) list because a comma delimiter does not work. If we choose to support any appserver sending an identity token, we can enter an asterisk (*) in this field. This action is called presumed trust. In this case, use client certificate authentication between appservers to establish the trust.

Set session management.

We can choose either stateful or stateless security. Performance is optimum when choosing stateful sessions. The first method request between a client and appserver 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, we have configured most of the information that a client gathers when determining what to send to this appserver. A client or appserver outbound configuration with this appserver inbound configuration, determines the security that is applied. When you know what clients send, the configuration is simple. However, if we have a diverse set of clients with differing security requirements, the appserver considers various layers of authentication.

For a J2EE appserver, the authentication choice is usually either identity assertion or message layer because you want the identity of the originating client delegated downstream. We cannot delegate a client certificate using an SSL connection. It is acceptable to enable the transport layer because additional appserver security, as the additional client certificate portion of the SSL handshake, adds some overhead to the overall SSL connection establishment.

 

Next steps

After you determine which type of authentication data this appserver might receive, we can determine what to select for outbound security. For more information, see Configuring CSIv2 outbound authentication.

CSIv2 inbound communications settings

 

Related tasks

Set CSIv2 outbound communications
Set CSIV2 inbound and outbound communication settings
Identity assertion to the downstream appserver