ORACLE

Many security architects have the false impression that configuring two-way SSL is sufficient to verify the client and restrict access to only trusted clients. This is actually not the case. In fact, many people set up two-way SSL with Verisign and nothing else, despite the fact that Verisign is designed only for trust—not for authentication or any other type of application access restriction, for that matter.
In this how-to you will learn how to create a custom user name mapper class that maps various certificate attributes to a user in your security realm that you can then authenticate and use to restrict or allow access to your application. It will also cover how to configure your Oracle WebLogic application server to be used to authenticate the certificate passed to the server from the client to restrict client access to your application.
We have been in countless meetings where the customer will suggest using two-way SSL to verify the client's identity and to use it to restrict access to the application. In almost every case, the customer wants to use a trusted third party to verify the identity of the certificate. This makes complete sense because you want a trusted third party to verify the identity of the certificate, but setting up two-way SSL without any certificate authentication—at least in Oracle WebLogic Server—will all allow clients with a valid Verisign certificate to connect to your server. This is usually not what the customer wants, especially in most cases where customers are using two-way SSL.
It is important to remember SSL is import for data encryption since the data you are sending is encrypted, and having two-way SSL means two ends of the connection establish trust using the X509 certificate type. However, certificate-based authentication is used to authenticate a user to the WebLogic server based on a digital certificate, and many types of certificates/tokens can be used including X509, X501, and CSlv2. For the purpose of this article only the X509 certificate type will be discussed.
When we suggest that setting up two-way SSL will not enable certificate-based authentication for connecting applications without some changes, most clients propose to make the changes on the firewall or use connection filters on WebLogic to protect their application instead of implementing certificate-based authentication. Both ideas are good ones, but they should complement the certificate-based authentication process for maximum security. We all know that spoofing IPs is quite possible, so setting up as many barriers as possible to only allow trusted clients to connect to your applications is critical.
In the example described here we implement the Custom User Name Mapper option of the default identity assertor as we could find no examples of how to develop this class. WebLogic does come with the default user name mapper, which can do simple mappings of various X509, X501, and CSlv2 certificate attributes to users. The custom user name mapper option originally was created for more custom user name mappings outside the basics that the default user name mapper offers. In our example, the custom user name mapper maps the CN attribute of an X509 certificate to a valid user.
You can download a zip containing the custom user name mapper class that maps the CN to a user in the Weblogic security realm You can easily update the class to map any X509 certificate attribute to a valid user in the security realm, or customize it using the class as a template. For the purpose of our example, we will assume you have already set up two-way SSL.
We compiled the class as in the screen shot below and then added the class to a JAR file, which we later added to all the classpaths of the servers within our domain.