The following describes a setup for dynamically choosing the client certificate used for SSL Authentication from an Axis Client.
This method has been tested using Axis 1.4 and Java 1.5 under Tomcat 5.5.20 and WebSphere 6.1.
Generally, a client will use one client certificate to identify itself to services it is accessing. Depending on the application, the client certificate will belong to the user of the application, or will be part of the installation of the application client itself.
Sometimes this model is insufficient:
- Perhaps more than one service needs to be accessed by the client, and the client is not free to choose the certificates used for access. In this case the client will need to work with the (multiple) certificates provided.
- In some cases the client will be acting "on behalf" of more than one user, and will want to employ the different user's different certificates to authenticate against backend systems.
Whatever the reason, sometimes the "one client, one certificate" model is not applicable. In this case, the client has to work, dynamically at run-time, with more than one certificate at a time.
In its current implementation, the SSL Transport for Axis has several shortcomings:
The base SecureSocketFactory (JSSE!SocketFactory) cannot be configured dynamically. It is configured using environment variables, which is not suitable if it is desired to change the client certificate at run-time.
The SunJSSE!SocketFactory is more configurable, accepting a keyfile parameter from the Axis configuration at run-time. This is the one to use, however, by itself it does not do all that we need, so we have provided an extension of this class (see below)...
Even the SunJSSE!SocketFactory does not accept all the configurations we need (eg: truststore config)
Even were the SocketFactory fully configurable to our desires, dynamic configuration at runtime would not be possible. This is beacause Axis caches the instantiated SocketFactories, meaning settings are applied only once.
The cacheing of SocketFactories occurs in a component called SocketFactoryFactory, the cache remembers one entry per protocol. So, the moment you make the first call over https, a SocketFactory is created for the protocol https using the currently configured parameters. After this no new SocketFactories are created for https, even if the parameters (eg keystore name) change.
So, it seems we are in a bind if we want to enable dynamic runtime selection of the client certificate.
The solution depends on a few modified classes for Apache Axis. In particular the solution consists of:
A modified SocketFactoryFactory, which implements a cacheing scheme in which the keystore name is considered
An extension to SunJSSE!SocketFactory which allows more configuration from Axis
An Axis EngineConfiguration class, SSL!ClientAxisConfig, which holds the SSL paramters, and sets everything up
Together, use of these components allows the desired dynamic configuration.
Usage / Configuration
To set up dynamic certificates for your axis client, proceed as follows:
Replace the SocketFactoryFactory class with your new version. This can be done in one of three ways (method 1 is safest):
- Find the original class file within axis.jar (it lives in org/apache/axis/components/net) and delete it, replace it with the modified class file
- Place the modified class file in a new JAR, and make sure this JAR loads before axis.jar (eg call it _axis.jar)
- For webapps, place the modified class file within your WEB-INF/classes folder. It seems tomcat loads these before axis.jar
- Add the remaining classes to your application
Use the SSL!ClientAxisConfig class to initialize your Axis client before making a call (see example below)
When you want to use a different certificate, create a new SSL!ClientAxisConfig, with updated paramters, and use it to create a new Axis client. This client will use the new certificate.
Example usage of the SSL!ClientAxisConfig:
1 // create config 2 boolean logging = false; // no logging 3 SSLClientAxisEngineConfig axisConfig = new SSLClientAxisEngineConfig(); 4 axisConfig.setKeystore("/path/to/clientkey.p12"); 5 axisConfig.setKeystoreType("PKCS12"); 6 axisConfig.setKeystorePassword("changeit"); 7 axisConfig.setTruststore("/path/to/truststore.jks"); 8 axisConfig.setTruststoreType("JKS"); 9 axisConfig.setTruststorePassword("changeit"); 10 if (logging) 11 axisConfig.setDebugBaseDir("/path/to/logs"); 12 axisConfig.initialize(logging); 13 // initialize service 14 URL soapURL = new URL("https://myserver.com/myapp/services/mywebserviceport"); 15 MyWebServiceServiceLocator locator = new MyServiceLocator(axisConfig); 16 MyWebServicePort port = locator.getMyWebServicePort(soapURL); 17 MyWebServiceBindingStub stub = (MyWebServiceBindingStub) port; 18 // make a call to the webservice (assume no params for this operation) 19 MyResultType result = stub.myoperation1();
Note: In the example above it is assumed that you have created the client stubs for the web service "MyWebService" using the Axis WSD!L2Java tool.
Note: Don't use the logging features in production setups, they are aides for development, and not implemented in sufficient quality to use in production.
Getting the code
- The code can be downloaded in compiled form (Java 1.5, Sun compiler) as a JAR archive: axistools.jar
- The source code can be downloaded from the following link, also as a JAR archive:axistools-src.jar
Note that both JARs contain all the classes described above, as well as the classes needed for the logging features.
Note that the SocketFactoryFactory replacement class is also included in the JARs, but may need to be moved elsewhere depending on your setup (see above) to ensure it loads before the original class in axis.jar.
Because the SocketFactoryFactory is not a "exchangeable component" of Axis, the class from the original Axis distribution must be replaced with the new version. This can be inconvenient.
Currently there is no limit to the number of SocketFactories cached in the SocketFactoryFactory. Thus, for setups running a long time without restarts, and using very many different client certificates, out-of-memory related problems might occur as the cache grows too large.
- Currently the cacheing is implemented using the keystore name as a key for the cache. If you replace the certificate in the keystore, the new certificate will not be picked up, as the old cache entry will be used (filename is the same).
For the same reason, changeing only the truststore or other parameters of the SSL connection will not result in a new SocketFactory being created. New SocketFactories are only created in the cache when the keystore name changes.
- The classes more or less assume software certificates, stored in files of the usual formats (JKS, PKCS12, etc). Usage of Hardware certificates or other advanced JSSE features may require modifications to the code.
Comments, Feedback, Support
This code is supplied back to the apache foundation, without any support or warranty. Use at your own risk. The author and his employer assume no responsibility for damages resulting in the use of this code or these instructions.
Feel free to use the code in any way you want but do not expect support.
Should you have questions about the code, please feel free to contact me (the Author) at: runger --AT-- aon.at