Łukasz Pijanowski wrote: > > Now I want to turn on HTTPS to secure the connection additionally. As > I understand, you have to add <http:conduit> configuration element to > the client configuration. >
You can as an additional safeguard, but so long as you are encrypting and signing, I believe that's redundant (and computationally expensive). I would check your Wireshark results with and without SSL to see the difference--see bottom of this link: http://www.jroller.com/gmazza/entry/implementing_ws_security_with_the . Łukasz Pijanowski wrote: > > I was thinking how the client is going to authenticate if there is no > explicit certificate alias mentioned in the configuration? Maybe the > client will use the certificate of the application server (Glassfish > v2) it is working on? > I don't believe the service uses the alias name--there are actual multiple key reference mechanisms available in the SOAP request--Subject Key Identifier, Thumbprint, Issuer, etc.: http://www.jroller.com/gmazza/entry/using_openssl_to_create_certificates (openssl is needed by Metro only, not CXF, btw). If you look at the WSS4J-encrypted SOAP request (see bottom of above link again--do this before you encrypt via SSL), you'll see the reference mechanism used by WSS4J. Incidentally, the reference mechanism used by default with WSS4J may or may not be optimal...I have not researched that enough yet. The most important thing is that the client's public key is imported into the WSS4J-defined truststore of the web service (*not* the JEE server's truststore). See step #6, servicekeystore.properties at the link at the top. HTH, Glen -- View this message in context: http://www.nabble.com/CXF-over-HTTPS-on-Glassfish-and-Tomcat-tp18729679p19042449.html Sent from the cxf-user mailing list archive at Nabble.com.
