Problem with message signed twice

[Roman Langfeld <la...@gmx.de>]

Hi All,

I have a problem verifying a SOAP message using WSDoAllReceiver. The message is signed twice with two different certificates where the first cert signs an element in the header and the second cert signs the body. There is one <Security> element containing two <Signature> elements.

The verification itself seems to work, at least I get this message:
[Reference] Verification successful for URI "#id-3125250"
[Reference] Verification successful for URI "#id-1456470"

But then the following exception is thrown:
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
 faultSubcode: 
 faultString: WSDoAllReceiver: security processing failed (actions number mismatch)
 faultActor: 
 faultNode: 
 faultDetail: 
 {http://xml.apache.org/axis/}stackTrace:AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
 faultSubcode: 
 faultString: WSDoAllReceiver: security processing failed (actions number mismatch)
 faultActor: 
 faultNode: 
 faultDetail: 
 
I located the source of the error down to the invoke() method of the WSDoAllReceiver class where the size of the returning vector that results from calling processSecurityHeader() is compared to the number of actions identified by calling AxisUtils.decodeAction() (also from within WSDoAllReceiver):

  /*
    * now check the security actions: do they match, in right order?
    */
  int resultActions = wsResult.size();
  int size = actions.size();
  if (size != resultActions) {
   throw new AxisFault("WSDoAllReceiver: security processing failed (actions number mismatch)");
  }

The actions seem to be those specified for the handler in the deployment descriptor. In my test I set the parameter action to "Signature".

So in this case the vector has two entries while there is only one action, which is why the comparison fails and the above error is thrown.

Why is the number of actions defined in the deployment descriptor related to the number of Signatures (or encryptions) contained in a <Security> header? As far as I understand the specification a scenario like the one described above is a valid one, right?

Maybe I'm on a complete wrong track in which case I hope you can help me out or maybe anyone can use this info to fix the problem :)

Thanks and have fun!
Roman