As we saw earlier in Example 16-1, when a Java client creates a JNDI context bound to a server configured for two-way SSL, the server authenticates the client on two levels:
At the socket level, where the client’s certificate is validated at the server’s end. A server configured for two-way SSL needs to trust the client’s certificate before it can successfully negotiate the SSL connection. A similar situation arises when you use a browser to access a web application that enforces authentication using client certificates.
At the application-level, where WebLogic takes the user’s credentials to populate the client’s subject with valid WebLogic principals. WebLogic subsequently uses this subject to perform authorization checks on protected server-side resources.
If the client needs to interact with an SSL server configured for two-way SSL, the client will be requested to present its digital certificate to prove its identity. The client’s certificate can perform the dual role of identifying the WebLogic principals that map to the client. After all, a client’s certificate does affirm its identity. WebLogic lets you configure the server so that it can map the client’s certificate to the username of a valid WebLogic user. In this way, a Java client can securely establish a JNDI context that is bound to an SSL server by supplying only its private key and digital certificate, and WebLogic will map the client’s certificate to a username.
Typically, a ...