Wildfly's JAXWS implementation seems to ignore bindingProvider property com.sun.xml.ws.transport.https.client.SSLSocketFactory

Question

My environment is a Maven Project and Wildfly (8.2.1) as Application Server. What I need is to connect wihin a incoming REST call to a third party server using SOAP. I need SSL Client Authentication; therefore, I have my own KeyStore and TrustStore. I create therefore my own SSLContext and need to let the WebService use this SSLContext.

There is a problem with Wildfly and it's used implementation of JAXWS (Apache CXF?) - I described it here (but with another aproach to solve the problem; therefore it is not a duplicate post!):
Wildfly: How to use JAXWS-RI instead of Apache CXF (WebService client only)

One of the main problems seems to be that JAXWS used in Wildfly seems to ignore setting the own SSLContext with property com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory:

MyWS_Service service = new MyWS_Service(null, new QName("http://...", "MyWS"));
MyWS port = service.getMyWSSOAP();

BindingProvider bindingProvider = (BindingProvider) port;
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://hostname:443/.../...");

// the following setting is ignored!
bindingProvider.getRequestContext().put("com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

// in some posts, we see that we need to eliminate 'internal' in the property. This does not help!
bindingProvider.getRequestContext().put("com.sun.xml.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

The proof that it is ignored is that if I use HttpsURLConnection.setDefaultSSLSocketFactory(mySslSocketFactory) to set the SSLContext, it does work - means the SSL connection is established thanks to the imported root CA to the customized TrustStore setup in the SSLContext.

If we look at other posts (e.g. How to programmatically set the SSLContext of a JAX-WS client?) this property should work (even for Wildfly according some comments there). But it does not in my situation. What can be the cause of this?

Mahratta

As described in my comment on your previous post I really think the problem is the com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory reference. Did you see this comment? https://mcmap.net/q/294101/-how-to-programmatically-set-the-sslcontext-of-a-jax-ws-client – Tandem

Yes, you are right. It is definitively ignored because Wildfly uses CXF. I also found a solution which I will post next week here.. What I did not understand is that someone posted that it should work in Wildfly with this property set: https://mcmap.net/q/294101/-how-to-programmatically-set-the-sslcontext-of-a-jax-ws-client. – Mahratta

Answer 1

The problem is definitifely that Apache CXF ignores

bindingProvider.getRequestContext().put(
    "com.sun.xml.[internal.]ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

in oposite to some comments some where.

So my final solution is to programmatically setup the HTTPConduit used (rather than set a config in a cxf.xml file).

// Set custom SSLContext.
HTTPConduit conduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
TLSClientParameters tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setSSLSocketFactory(customSSLContext.getSocketFactory());
conduit.setTlsClientParameters(tlsClientParameters);

I hope that this helps someone having similar issues...

Mahratta

Please, how do you did that? If I try to use the TLSClientParameters class I get the error "java.lang.NoClassDefFoundError: org/apache/cxf/configuration/jsse/TLSClientParameters". I'm using the jbossws-cxf-client artifact on my POM . – Unfix

Answer 2

Apache CXF ignores the JAX-WS properties. You can specify the TLS Client Parameters programmatically the following way:

TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setUseHttpsURLConnectionDefaultSslSocketFactory(false);
tlsParams.setSSLSocketFactory(sslSocketFactory);
bindingProvider.getRequestContext().put(TLSClientParameters.class.getName(), tlsParams);

Sutlej

Vladimir it works ! I wonder where did you find it. – Accession

I am usin Wildfly 22 and it's throwing exception in runtime: ClassNotFound for TLSClientParameters. Any solution? – Guanine

Answer 3

When using the HTTPConduit solution for Wildfly 10 I had to add jboss-deployment-structure.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
        <dependencies>
  <module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import" />

  <module name="org.apache.cxf.impl" export="true">  
       <imports>  
            <include path="META-INF" />  
            <include path="META-INF/cxf" />  
            <include path="META-INF/services" />  
       </imports>         
  </module>   
        </dependencies>
    </deployment>

</jboss-deployment-structure>

Porty

Answer 4

My solution to Widfly 8.2.1:

1) Add the file src/main/resources/META-INF/services/javax.xml.ws.spi.Provider with the line com.sun.xml.ws.spi.ProviderImpl inside

2) Add the maven dependency:

<dependency>
     <groupId>com.sun.xml.ws</groupId>
     <artifactId>jaxws-rt</artifactId>
     <version>2.2.8</version>
</dependency>

3) Add the SSLSocketFactory this way:

bindingProvider.getRequestContext().put("com.sun.xml.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);

Slattern

Answer 5

In my case I could solve it using:

bindingProvider.getRequestContext().put(JAXWSProperties.SSL_SOCKET_FACTORY, sslSocketFactory);

Borchert