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.
1 of 1 people found this helpful
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.
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.
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.
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!