Note that those keys/values can be set on the clients request context as well:
((BindingProvider)proxy).getRequestContext() .put( SecurityConstants.ENCRYPT_CRYPTO, crypto); Within CXF, when we ask for the various crypto things, if it already is a Crypto object, we use it. Otherwise we assume it the properties needed to create the Crypto. Dan On Nov 20, 2012, at 9:24 AM, Andrei Shakirin <[email protected]> wrote: > Not WS-Security policy properties, but SecurityConstants.ENCRYPT_CRYPTO > (ws-security.encryption.crypto) and SecurityConstants.SIGNATURE_CRYPTO > ws-(security.signature.crypto) properties. They are not directly bound with > WS-Security Policy. > You have to say WSS4J interceptors that they should use custom crypto > provider, not standard Merlin. It is possible to achieve it through message > properties. > There are different possibilities to do it: in your client/service business > code or in custom interceptor. With interceptor solution you will be able to > reuse solution for some clients and services. > > Cheers, > Andrei. > >> -----Original Message----- >> From: martin [mailto:[email protected]] >> Sent: Dienstag, 20. November 2012 14:09 >> To: [email protected] >> Subject: RE: Expanding a webservice client to handle changing keys. >> >> So what you are doing is using an interceptor to define the WS-Security >> policy >> properties before the WSS4J interceptors are invoked, is that correct? >> >> >> >> -- >> View this message in context: http://cxf.547215.n5.nabble.com/Expanding- >> a-webservice-client-to-handle-changing-keys-tp5718802p5718827.html >> Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
