Hi Martin I might have used the TLSClientParameters example imprecisely. I focused primarily on the API exposing the ability to set the arrays of KeyManagers and TrustManagers directly.
Please do correct me if I’m wrong, but as far as I know WSS4J primarily deals with KeyStores and TrustStores in relation to doing message-level encryption, signing, decryption and signature verification. It is not my understanding that WSS4J actually works with sockets. We are expecting to create a crypto provider similar to org.apache.wss4j.common.crypto.CertificateStore except it should also be able to handle encryption and signing. However it sounds like you have a broader perspective on this? Thanks for the support! I hope we can create something useful. Kind regards Jesper From: Martin Gainty <[email protected]> Sent: 10. juli 2019 19:23 To: [email protected] Subject: Re: Alternative to Merlin crypto provider a great idea for expanding WSS4Js capability to handle other crypto providers! if you're in TLSClientParameters take a look at: /* Returns whether or not {@link javax.net.ssl.HttpsURLConnection#getDefaultSSLSocketFactory()} should be * used to create https connections. If <code>true</code> , {@link #getJsseProvider()} , * {@link #getSecureSocketProtocol()}, {@link #getTrustManagers()}, {@link #getKeyManagers()}, * {@link #getSecureRandom()}, {@link #getCipherSuites()} and {@link #getCipherSuitesFilter()} are * ignored. */ theoretically your new implementation of SSLSocketFactory once set thru tlsClientParameters.setSSLSocketFactory(JesperSSLSocketFactory) would 'provide' the necessary requisite attributes: JsseProvider TrustManagers KeyManagers /* some helpful Info from JSSE doc page: */ Obtaining an SSLSocketFactory There are three primary ways of obtaining an SSLSocketFactory: · Get the default factory by calling the SSLSocketFactory.getDefault static method. · Receive a factory as an API parameter. That is, code which needs to create sockets but which doesn't care about the details of how the sockets are configured can include a method with anSSLSocketFactory parameter that can be called by clients to specify which SSLSocketFactory to use when creating sockets. (For example, javax.net.ssl.HttpsURLConnection.) · Construct a new factory with specifically configured behavior. The default factory is typically configured to support server authentication only so that sockets created by the default factory do not leak any more information about the client than a normal TCP socket would. Many classes which create and use sockets do not need to know the details of socket creation behavior. Creating sockets through a socket factory passed in as a parameter is a good way of isolating the details of socket configuration, and increases the reusability of classes which create and use sockets. You can create new socket factory instances either by implementing your own socket factory subclass or by using another class which acts as a factory for socket factories. One example of such a class is SSLContext, which is provided with the JSSE implementation as a provider-based configuration class. once coded your new crypto provider would be specifed in $JRE_HOME/lib/security/java.security as security.provider.1 ? https://doc.bccnsoft.com/docs/jdk7-docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLSocketFactory is this you're thinking? i support your efforts in expanding crypto providers for WSS4 and would like to help this important effort any way i can M- ________________________________ From: Jesper Duelund Isaksen <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 9, 2019 7:22 AM To: [email protected]<mailto:[email protected]> Subject: RE: Alternative to Merlin crypto provider Thanks for the very quick reply! Alright, so a custom provider is the way to go. We are only experimenting at the moment so I am unsure if we will get to the point of having something good enough for contribution. The SVN repository is the correct place to branch out a separate contribute I assume? Kind regards Jesper From: Colm O hEigeartaigh <[email protected]<mailto:[email protected]>> Sent: 9. juli 2019 10:12 To: [email protected]<mailto:[email protected]> Subject: Re: Alternative to Merlin crypto provider Contributions to the project involving new Crypto implementations would be very welcome :-) Colm. On Tue, Jul 9, 2019 at 8:02 AM Jesper Duelund Isaksen <[email protected]<mailto:[email protected]>> wrote: Hi Does anyone know if an alternative to Merlin already exists that allows configuring Apache WSS4J with in-memory KeyStores, KeyManager and TrustManager or similar? Perhaps something similar to what is exposed in CXF using the org.apache.cxf.configuration.jsse.TLSClientParameters class? We experimenting with a common security library implementation on top of Apache CXF for a set of services with a common WS-Trust-like security model intended to be running in containers. It would be great if secrets could be fetched from a system like HashiCorps Vault or similar, however this seems to conflict with using static JKS keystores for the WSS4J configuration. Alternatively it would perhaps be an idea to implement a custom crypto provider? Are there any critical pitfalls to be aware of, if this the way to go? Kind regards Jesper Duelund Isaksen -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
