FIY I also needed to implement this and have nearly got it working.
The key to cracking the solution was to:
1. Use @WebServiceProvider to implement the receiving endpoint -- the
JAXB bindings won't work if the message is not processed (especially if
encryption is used), so you'll need to work with the XML.
2. Convince CXF that WS-Security headers were "understood", even though
the receiving endpoint was not using the WSS4JInInterceptor.
I managed to achieve (2) using my WSSPassThroughInterceptor which I
posted here:
http://old.nabble.com/Fake-the-understanding-of-a-%22soap%3AmustUnderstand%22-header-tp26475723p26497127.html
Hope this helps you solve your case.
P.S. BTW, I use Camel to inject a "middle-man" before routing the
message to the ultimate destination, but depending on your use-case, you
might make do with simply using CXF interceptors.
Daniel Kulp wrote:
On Mon November 16 2009 12:49:07 pm Howard Points wrote:
We have a DataPower appliance sitting in front of our web service and
encrypting a single field in the SOAP request. This is passed into our web
service. We just want to pass through the encrypted field to a down line
another web service call. We do not want to decrypt the value in the middle
web service (for PCI compliance reasons). Is there a way to do this in CxF?
I guess there isn't enough details to answer the question. Obviously, you
could just disable the security stuff and then CXF would leave everything
alone. Do you need SOME stuff processed but other things left alone? I'm
not sure if that's doable. I THINK wss4j will just process the entire
security header. Maybe some interceptor that strips some entries out of the
security header. Not really sure. :-(
Dan
Thanks
Howard
