Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The "FrontPage/Axis/DynamicSSLConfig" page has been changed by Mike Murphy: http://wiki.apache.org/ws/FrontPage/Axis/DynamicSSLConfig?action=diff&rev1=9&rev2=10 This method has been tested using Axis 1.4 and Java 1.5 under Tomcat 5.5.20 and !WebSphere 6.1. === The Motivation === - 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: @@ -20, +19 @@ 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. === The Problem === - 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. + * 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 === + The solution depends on a few modified classes for Apache Axis. In particular the solution consists of: - 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 @@ -41, +39 @@ Together, use of these components allows the desired dynamic configuration. === Usage / Configuration === - To set up dynamic certificates for your axis client, proceed as follows: 1. Replace the !SocketFactoryFactory class with your new version. This can be done in one of three ways (method 1 is safest): - 1. 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 + 1. 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 - 1. Place the modified class file in a new JAR, and make sure this JAR loads before axis.jar (eg call it _axis.jar) + 1. Place the modified class file in a new JAR, and make sure this JAR loads before axis.jar (eg call it _axis.jar) - 1. For webapps, place the modified class file within your WEB-INF/classes folder. It seems tomcat loads these before axis.jar + 1. For webapps, place the modified class file within your WEB-INF/classes folder. It seems tomcat loads these before axis.jar 1. Add the remaining classes to your application 1. Use the SSL!ClientAxisConfig class to initialize your Axis client before making a call (see example below) 1. 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: + {{{#!java // create config boolean logging = false; // no logging @@ -74, +72 @@ // make a call to the webservice (assume no params for this operation) 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: For an explanation of the logging features, please see [[FrontPage/Axis/Logging/Logging_with_SSL]] and [[FrontPage/Axis/Logging/In_Memory_Logging]] @@ -82, +79 @@ /!\ 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 @@ -93, +89 @@ 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. === Shortcomings === - * 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 + Should you have questions about the code, please feel free to contact me (the Author) at: runger --AT-- aon.at --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
