5 Replies Latest reply on May 9, 2013 4:31 AM by bodzolca

    JAXWSProperties.SSL_SOCKET_FACTORY alternative in JBoss


      I have WS clients inside the application server making web services calls out to other servers. I need to specify the SSLSocket factory to be used by the request (as I have custom keystores and trust stores).


      The first obvious solution is to set the default SSLSocketFactory of the HttpsURLConnection:

      {code}// SSLSocketFactory factory = ...




      This works fine on both JBoss 5.1.0 and GlassFish 3.1.2 as long as all SSL connections in the VM can use the same truststore/keystore and keys.


      However in my case I want to be able to connect to different servers using different keystores and having multiple concurrent requests. This means that setting the SSLSocketFactory globally for the VM is not an option.


      Instead the JAX-WS RI offers an way of specifying the SSLSocketFactory per request:

      {code}import com.sun.xml.ws.developer.JAXWSProperties;


      EjbcaWS ejbca = service.getEjbcaWSPort();

      BindingProvider binding = (BindingProvider) ejbca;

      Map<String, Object> requestContext = binding.getRequestContext();

      requestContext.put(JAXWSProperties.SSL_SOCKET_FACTORY, factory);{code}


      This achieves exactly the functionality I need and works perfect on GlassFish, however the property is ignored by JBoss 5.1.0.GA-jdk6.


      Is there a similar property that JBoss uses or how can I achive different SSL socket factories per request?

        • 1. Re: JAXWSProperties.SSL_SOCKET_FACTORY alternative in JBoss

          The BindingProvider properties you've referred to only apply to message level certificate usage (XML signing and encryption). For per client transport layer settings (there's a JIRA on this), the easiest thing to do is to download the jbossws source, modify it and rebuild it. I posted the revised code not too long ago on one of my open JIRA tickets. Perhaps you can find it.

          • 2. Re: JAXWSProperties.SSL_SOCKET_FACTORY alternative in JBoss

            Thank you spyhunter99 for your reply.


            I am not sure I fully understood what you mean. Are you saying that JAXWSProperties.SSL_SOCKET_FACTORY is used by JBossWS-native but not for the transport layer (as it is for JAX-WS RI/metro)?


            Rebuilding JBossWS-native isn't really something I would like to do trying to build an portable JEE application. However, I have done some more searching on the issue and found out that it is possible to achieve the same functionality as in JAX-WS RI by switching to JBossWS-cxf and use some custom code to set the TlsSettings. Not optimal as it would require the Apache CXF at compile-time and I would have to check if it is available at runtime as it will not be when running on GlassFish but anyway.

            1 of 1 people found this helpful
            • 3. Re: JAXWSProperties.SSL_SOCKET_FACTORY alternative in JBoss

              No, I'm stating that out of the box, the request message context parameters that you pass it, such as javax.net.ssl.truststore and keystore are not picked up from there or from system.properties. It will however pickup key stores for message level encryption and signing, not transport. I haven't explicitly looked for the SSL_SOCKET_FACTORY's usage, but I've haven't stumbled upon it.


              If you want per web service client SSL sessions with their own key/trust stores, you either have to rebuild jboss-native from source (which is easy) and patch it (also easy), or switch to jbossws-cxf and use the httpconduit class to setup the trust stores.

              • 4. Re: JAXWSProperties.SSL_SOCKET_FACTORY alternative in JBoss

                Ok thank you, then I will probably go with the switching to jbossws-cxf as I can not require my users to patch the application server manually. Also making changes to the web services stack implementation doesn't sound like something you can do in the supported JBoss EAP version.




                • 5. Re: JAXWSProperties.SSL_SOCKET_FACTORY alternative in JBoss

                  I'm confused here. Isn't your answer in direct contradiction with the fact that it works by setting the system properties? It doesn't matter whether this 'solution' is unsatisfactory, it just works. I'm probably missing something obvious.


                  Markus, another question for you. Were you successful in switching to jbossws-cxf? Did you run into problems discussed here?


                  Thanks to both!