It's easiest to submit a pull request here instead: https://github.com/apache/wss4j
Colm. On Tue, Jul 9, 2019 at 12:22 PM Jesper Duelund Isaksen < jesper.duelund.isak...@systematic.com> wrote: > 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> 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 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
