I am encountering a digest verification problem when using the WSSecurityEngine.processSecurityHeader() method. The problem occurs when the EnvelopeIdResolver.engineResolve() method calls WSSecurityUtil.findBodyElement().
The call is: Element selectedElem = WSSecurityUtil.findBodyElement(doc, sc); In the original document (doc parameter) the body tag is as follows: <SOAP-ENV:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="id-4423115"> The selectedElem returned by the findBodyElement() method has a body tag like this: <SOAP-ENV:Body xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; wsu:Id="id-4423115"> As you can see, the part in bold has been added. I suppose it is inherited from the original Soap envelope, which encapsulates the body: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";> The trouble is now that the digest value is recalculated by the receiving side on the modified body (the one containing the SOAP-ENV namespace) and of course it does not match the digest value calculated by the sender on the original body. I get a hash mismatch and the message is rejected by the receiver. The funny thing is that when I calculate the hash at the sender's side, the exact same call is executed to find the body element, i.e. findBodyElement(), but this time the body tag is not modified. Is there somewhere a property (on the Document level perhaps?) indicating if the namespace should be transfered from the Envelope tag to the Body tag when the findBodyElement() call is executed? Quite puzzled... Regards, Rik Gruwez -- View this message in context: http://www.nabble.com/Body-attributes-get-modified-when-verifying-digest-tp22718268p22718268.html Sent from the WSS4J mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
