Bugzilla – Bug 2471
Signature Verification Issues
Last modified: 2007-09-12 16:31:54
You need to
before you can comment on or make changes to this bug.
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:
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):
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:
signature or decryption was invalid
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Error: ; nested exception is:
javax.xml.rpc.soap.SOAPFaultException: The signature or decryption
If you want to try things out for yourself you should be able to connect to
a test counter service
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:
Adding a wsa prefix to the Address element:
manages to coax the service into returning more reasonable XML for the To
header (no namespace definition):
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.
Btw, I think this issue has come up on the axis discussion list before. It's
pretty much a bug in axis.
It seems it is an Axis bug. There's a JIRA report for it at
Was there ever any resolution for this? It's causing some unfortunate interop
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
(doesn't look like it's been committed yet though, I'm not sure why).
It'd be nice to finally have this fixed.
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?
Reassigning to current wsrf developer to close/fix as appropriate.