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 <cohei...@apache.org>
Sent: 9. juli 2019 10:12
To: users@ws.apache.org
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 
<jesper.duelund.isak...@systematic.com<mailto:jesper.duelund.isak...@systematic.com>>
 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

Reply via email to