I'm new to soapUI 2.5, but when I create a simple SOAP request, it's fine, and is accepted by my server. When my SOAP request is encrypted, again it works fine too as does a signed SOAP request. But if I BOTH sign AND encrypt (or encrypt then sign) my request then the server is rejecting it.
My server is Mule using cxf, which uses the wss4j-1.5.4 library. I've tried wss4j-1.5.5 too without success.
The server (Mule 2.1.1) error looks like:
org.apache.ws.security.WSSecurityException: An error was discovered processing the header at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:228) at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:65) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78) at org.mule.transport.cxf.CxfServiceComponent.sendToDestination(CxfServiceComponent.java:283) at org.mule.transport.cxf.CxfServiceComponent.onCall(CxfServiceComponent.java:112) at org.mule.model.resolvers.CallableEntryPointResolver.invoke(CallableEntryPointResolver.java:52) at org.mule.model.resolvers.DefaultEntryPointResolverSet.invoke(DefaultEntryPointResolverSet.java:50) at org.mule.component.DefaultLifecycleAdapter.invoke(DefaultLifecycleAdapter.java:197) at org.mule.component.AbstractJavaComponent.invokeComponentInstance(AbstractJavaComponent.java:83) at org.mule.component.AbstractJavaComponent.doInvoke(AbstractJavaComponent.java:74) at org.mule.component.AbstractComponent.invokeInternal(AbstractComponent.java:125) at org.mule.component.AbstractComponent.invoke(AbstractComponent.java:153) at org.mule.service.AbstractService.invokeComponent(AbstractService.java:932) at org.mule.model.seda.SedaService.doSend(SedaService.java:229) at org.mule.service.AbstractService.sendEvent(AbstractService.java:505)
I've drawn a blank at the server end of things. I'm wondering whether it could be the way I'm signing then encrypting the message (and other way around) using the soapUI client in the first place.
hmm.. have you tried adding the encryption/signature configuration in the opposite order as the one you are using? They are applied in left-to-right order, which can not be changed (I know, this is really bad from a usability perspective and we will change it in next major release).
So, reading the post I downloaded the wss4j source and , as suggested near the botton, I changed the checkReceiverResults method to return true, recompiled it, ran up Mule, and sent my signed and encrypted message from soapUI. Result? Seemed to work just fine!
Now I need this for production use so I'm not happy leaving it like this, because it's simply bypassing a (necessary?) check to ensure the requested number of actions are actually done; so, it's cheating really!!!
The reason for posting in this forum is becuase of some other comments in the link above regarding .Net clients. Not being too familar with this stuff, I just wondered whether soapUI is generating a signed and encryted SOAP request, which, to my server, Mule running cxf and wss4j, it looks like a .Net client's SOAP request which is somehow incompatiable to the wss4j libraries? Maybe due to some embedded timestamp element or something?
Is any of this likely to be at the root of my problem?
Thanks for all your info. Actually soapUI uses wss4j for signing/encrypting, so this is even more puzzling.. The latest nightly builds have been upgraded to use wss4j 1.5.5, previous versions used 1.5.4 and 1.5.3.. What could we do to work around this? Add some kind of option in the UI?