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
