An additional way to authenticate a client to a server is using Secure Sockets Layer (SSL) client authentication.
Using SSL client authentication is another way of authenticating a client to a server. This form of authentication does not occur at the message layer using a user ID and password or tokens. This authentication occurs during the connection handshake using SSL certificates.
When the client is configured with a personal certificate in the SSL keystore file, which indicates that SSL client authentication is required and the server supports SSL client authentication, the following actions occur to establish the identity on the client side.
Because the configuration specifies SSL and SSL client authentication, the connection type is SSL and the SSL handshake sends the client certificate to the server to validate. If the client certificate does not validate, the connection is not established and an exception is sent back to the client code where the method is invoked, which indicates the failure. If the client certificate is validated, then a connection opens between the client and the server.
If basic authentication is also configured, for example, then the user might be prompted for a user ID and password. Because this action is not necessary, disable this option in the configuration if the SSL certificate is the identity against which to invoke the method. If a message layer security does not exist, then a security context is created and associated with the request.
Because the server does not find a service context, it checks the server socket for a client certificate chain that contains the client identity. In this case, the server finds the certificate chain from the client. The identity in the certificate chain is valid because the connection is made. To create a credential, map the identity from the certificate to the user registry. This action is done differently based on the type of authentication mechanism.
Mapping a certificate to a credential is done differently based on the user registry type.
See the Map certificates to users article, for details on how this mapping is performed for the Lightweight Directory Access Protocol (LDAP) user registry. For local OS, the first attribute of the distinguished name (DN) in the certificate is used to map to the user ID in the registry.
One benefit of SSL client certificate authentication is that it optimizes authentication performance because an SSL connection is typically created anyway. The extra overhead of sending the client certificate is minimal. While the client-side request interceptor performs no activity, the server-side request interceptor maps the certificate to a credential.
One disadvantage to this type of authentication is the complexity of setting up the keystore file on each client system. To enable SSL client certificate authentication on the client side, set the properties. This action is completed using the following two properties:
Indicating that SSL is required implies that every request must generate an SSL connection key. If a server does not support SSL, then the request fails. After you enable SSL by either supporting it or requiring it, you can enable some of the SSL features. To enable SSL client authentication, you can specify the following two properties:
The TL means transport layer. If you indicate that SSL client authentication is required, you only limit the ability to communicate with servers that support SSL client authentication. For a server to support SSL client authentication, that server must have similarly configured properties through the administrative console, and have an SSL listener port that is open to handle mutual authentication handshakes. Configuration of server properties are done through the administrative console.
SSL client certificate authentication from a Java client is only available using the Common Secure Interoperability Version 2 (CSIv2) protocol.
Related tasks
Configuring Secure Sockets Layer for Java client authentication