Bug 2471 - Signature Verification Issues
: Signature Verification Issues
Status: NEW
: Java WS Core
globus_wsrf_core
: unspecified
: PC All
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-12-16 09:24 by
Modified: 2007-09-12 16:31 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-12-16 09:24:06
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.
------- Comment #1 From 2004-12-16 11:25:26 -------
Btw, I think this issue has come up on the axis discussion list before. It's
pretty much a bug in axis.
------- Comment #2 From 2004-12-16 13:53:27 -------
It seems it is an Axis bug. There's a JIRA report for it at 
http://nagoya.apache.org/jira/browse/AXIS-1624

Was there ever any resolution for this? It's causing some unfortunate interop 
problems.
------- Comment #3 From 2005-01-28 09:28:41 -------
This signature handling problem (where Axis does not preserve canonical form 
during message processing), recently resurfaced on the WSS4J mailing list. The 
net result is that I ended up submitting an Axis patch for it to JIRA 
http://issues.apache.org/jira/browse/AXIS-1624
(doesn't look like it's been committed yet though, I'm not sure why).

It'd be nice to finally have this fixed.
------- Comment #4 From 2005-06-14 09:46:12 -------
Unfortunately it seems this bug was never actually fixed. It was eventually
resolved in Axis, but I guess the version of Axis used in GT4 was never updated,
which means that signatures don't always work. Is it possible to include a newer
version of Axis with GT4, or apply the patch (which can be found here:
http://issues.apache.org/jira/browse/AXIS-1624) to the Axis codebase GT4 uses?
------- Comment #5 From 2007-09-12 16:31:54 -------
Reassigning to current wsrf developer to close/fix as appropriate.