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]>
Sent: Tuesday, July 9, 2019 7:22 AM
To: [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]>
Sent: 9. juli 2019 10:12
To: [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
