During incoming message handling, message XML is not always preserved in 
canonical form, so signature verification can sometimes fail unexpectedly.

Suppose I have the a test service that sends a signed response that looks 
includes an element that looks something like this: 
<wsa:To 
xmlns="http://schemas.xmlsoap.org/ws/2004/03/addressing">http://schemas.xmlsoa 
p.org/ws/2004/03/addressing/role/anonymous</wsa:To> 

The problem seems to be that when this element gets processed on the GT4/Axis 
end the XML effectively gets deserialized and re-serialized before the 
signature gets checked. The difficulty is that the re-serialized XML is 
slightly different (canonical form does not seem to be preserved): 
<To 
xmlns="http://schemas.xmlsoap.org/ws/2004/03/addressing">http://schemas.xmlsoa 
p.org/ws/2004/03/addressing/role/anonymous</To> 

This is what the MessageLogging handler will show. Since the element itself 
contains a namespace definition, the serializer sees no reason to also 
include the wsa prefix (or more accurately the WS-Addressing namespace gets 
mapped to the empty namespace for that element). At any rate this causes the 
signature checking for this element to fail, since the XML is now different 
from the form that was originally sent (and used to compute the signature). 
The full stack trace looks something like this: 

org.globus.wsrf.impl.security.authentication.wssec.WSSecurityException: The 
signature or decryption was invalid 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.verifyXMLS 
ignature(WSSecurityEngine.java:262) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityResponseEngine.ve 
rifyXMLSignature(WSSecurityResponseEngine.java:144) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.handleSign 
atureElement(WSSecurityEngine.java:101) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.processSec 
urityHeader(WSSecurityEngine.java:502) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.processSec 
urityHeader(WSSecurityEngine.java:468) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.processSec 
urityHeader(WSSecurityEngine.java:381) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityResponseEngine.pr 
ocessSecurityHeader(WSSecurityResponseEngine.java:52) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityBasicHandler.hand 
leMessage(WSSecurityBasicHandler.java:40) 
       at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityClientHandler.han 
dleResponse(WSSecurityClientHandler.java:59) 
       at org.apache.axis.handlers.HandlerChainImpl.handleResponse 
(HandlerChainImpl.java:123) 
       at org.apache.axis.handlers.JAXRPCHandler.invoke 
(JAXRPCHandler.java:54) 
       at org.apache.axis.strategies.InvocationStrategy.visit 
(InvocationStrategy.java:32) 
       at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) 
       at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) 
       at org.apache.axis.client.AxisClient.invoke(AxisClient.java:160) 
       at org.apache.axis.client.Call.invokeEngine(Call.java:2719) 
       at org.apache.axis.client.Call.invoke(Call.java:2702) 
       at org.apache.axis.client.Call.invoke(Call.java:2378) 
       at org.apache.axis.client.Call.invoke(Call.java:2301) 
       at org.apache.axis.client.Call.invoke(Call.java:1758) 
       at com.counter.bindings.CounterPortTypeSOAPBindingStub.createCounter 
(CounterPortTypeSOAPBindingStub.java:758) 
       at org.globus.wsrf.samples.counter.client.CounterClient.main 
(CounterClient.java:96) 
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
       at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39) 
       at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25) 
       at java.lang.reflect.Method.invoke(Method.java:324) 
       at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:83) 
Error: ; nested exception is: 
       javax.xml.rpc.soap.SOAPFaultException: The signature or decryption 
was invalid 

If you want to try things out for yourself you should be able to connect to 
a test counter service 
(http://opteron7.cs.virginia.edu/CounterService/CounterService.asmx), 
presenting it with a signed message. (Note that secure conversation 
doesn't work, only secure message, so you'll have to configure the counter 
client to work this way if you use it). 

One possible work-around for this problem involves a small modification to the 
WS-Addressing library. Currently when that library serializes an 
EndpointReference Address (it doesn't put a wsa prefix on the <Address> tag. So 
for instance the From header looks like: 

<wsa:From xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- 
wssecurity-utility-1.0.xsd" wsu:Id="id-7960257" 
soapenv:mustUnderstand="0"><Address 
xmlns="http://schemas.xmlsoap.org/ws/2004/03/addressing">http://schemas.xmlsoa 
p.org/ws/2004/03/addressing/role/anonymous</Address></wsa:From> 

Adding a wsa prefix to the Address element: 
<wsa:Address 
xmlns="http://schemas.xmlsoap.org/ws/2004/03/addressing">http://schemas.xmlsoa 
p.org/ws/2004/03/addressing/role/anonymous</wsa:Address> 

manages to coax the service into returning more reasonable XML for the To 
header (no namespace definition): 
<wsa:To>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:T 
o> 

In that form, the XML can safely deserialized and re-serialized without 
losing anything from the original XML, so the signature will check out ok. 
Obviously, this fix still doesn't solve the larger issue that certain XML 
(even in canonical form) might get modified during axis processing, but 
before signature verification. Still, I think it will get the job done for me.