Configure CSIv2 inbound authentication

Inbound authentication 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.

  1. Start the administrative console.

  2. In the navigation menu, click Security --> Authentication Protocol --> CSI Inbound Authentication.

  3. Select settings for authentication types:

    • Basic Authentication (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 server. Usually, a token is sent from an upstream server and a user ID and password are sent from a client (including a servlet). When a user ID and password are received at the server, they are authenticated with the user registry. When a token is received at the server level, it is validated to determine whether the token is expired or has been tampered with.

    • Client Certificate Authentication (transport layer)
      This type of authentication typically occurs from pure clients that use the certificate identity, and from servers that trust the upstream server. Usually, when a server delegates an identity to a downstream server, it comes from either the message layer (a client authentication token) or the attribute layer (an identity token), not from the transport layer, through the client certificate authentication. A client has an SSL client certificate 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 it 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 it to a user in the 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.

    • 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 as the originating client presented it 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, since the identity is authenticating on this server. 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, then the identity token identity is put into a credential and used for authorization of the request.

    Consider the following points when deciding what type of authentication to accept:

    • A server 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 SSL client certificates authentication is used when it is the only layer provided. If the message layer and 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 server usually receive requests from a client, from a server or both? If the server always receives requests from a client, identity assertion is not needed. You can then choose either the message layer, the transport layer, or both. You also can decide when the 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 server user registries, then 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, then a principal identity is sent. If authentication is done with a certificate, then the certificate chain is sent. In some cases, if the client authenticated with a token and a Lightweight Directory Access Protocol (LDAP) server is the user registry, then a distinguished name (DN) is sent.

    • For an enterprise bean server, the authentication choice is usually either Identity Assertion or Basic Authentication because you want the identity of the originating client to be delegated downstream. You cannot easily delegate a client certificate with 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.

  4. Configure a trusted server list. When identity assertion is selected for inbound requests, insert a comma-separated list of server administrator IDs to which this server can allow identity tokens to be submitted. If you choose to allow any server to send 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.

  5. 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.

For more information about the settings, see the administrative console help topic, CSI inbound authentication settings. Go to Help documentation

After you determine which type of authentication data this server receives, you can determine what to select for outbound security.