[
https://issues.apache.org/jira/browse/RAMPART-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896624#action_12896624
]
Amila Jayasekara commented on RAMPART-303:
------------------------------------------
Hi Niall,
I was able to reproduce this issue. The cause this issue lies within axiom to
dom conversion code. Let me explain the issue in detail.
Rampart uses xmlsec implementation for xml encryption and signing operations.
But axis2 uses a its own xml object model called Axiom. When a request comes
Rampart has to convert message from axiom implementation to DOM implementation.
This was done by introducing a new model called DOOM. In this model an Element
implements DOM interfaces and Axiom interfaces. XmlSec uses 2 DOM interface
methods during canonicalization. They are Element.hasAttribute() and
Element.getAttributes(). The way these 2 methods implemented in DOOM is not
correct. The Element.hasAttribute() method returns true only if namespaces are
not null for current node. So if we have an element like "<drivingdirections
xmlns="">", the Element.hasAttribute() will return false in DOOM
implementation. But according to DOM interfaces method Element.hasAttribute()
should return true for "<drivingdirections xmlns="">" as there is a namespace
attribute attached to it.
I file an issue for this in [1] under WS-COMMONS and also submit a fix for that.
[1] https://issues.apache.org/jira/browse/WSCOMMONS-557
Also you are correct about https://issues.apache.org/jira/browse/RAMPART-128.
That is this issue shows resemblance of RAMPART-128. When the namespace of
drivingdirections is set to null, all namespaces underneath that element are
also set to null. Therefore Element.hasAttribute() method returns false for all
underneath elements.
If possible please apply the patch in [2] and see whether your issue is
resolved. You need to apply this to AXIOM code
(http://svn.apache.org/repos/asf/webservices/commons/${your axiom
version}/modules/axiom).
[2] https://issues.apache.org/jira/secure/attachment/12451599/WSCOMMONS-557.diff
Thank you
AmilaJ
> Incorrect XML Passed to Digest Algorithm when XML Elements Belong to Empty
> Namespace
> ------------------------------------------------------------------------------------
>
> Key: RAMPART-303
> URL: https://issues.apache.org/jira/browse/RAMPART-303
> Project: Rampart
> Issue Type: Bug
> Components: rampart-core
> Affects Versions: 1.5
> Environment: Windows XP
> Reporter: Niall Tierney
> Assignee: Ruchith Udayanga Fernando
> Attachments: correct.dat, driving_with_wspolicy.wsdl,
> DrivingClient.java, incorrect.dat, input.xml
>
>
> I am using Axis2 1.5.1 and Rampart 1.5 to sign a SOAP request and validate
> the signature on the response, however I am getting a mismatch between the
> actual digest in the XML Signature in the response message and the digest
> produced by Rampart.
> To investigate this issue, I implemented a simple Crypto provider that
> implemented the SHA1 digest algorithm. The provider just writes out the data
> that was sent to it to digest to a file. It then just calls the default Sun
> implementation to actually compute the digest. This allowed me to see the
> XML that Rampart was passing to the digest algorithm.
> The attached input.xml is the initial signed response document.
> When verifying the signature on the response body, rampart produces the
> following output:
> > WARNING: Expected Digest: uf7xYFDKnUgQgxBg3SJTSIY/osk=
> > 26-Jul-2010 10:54:56 org.apache.xml.security.signature.Reference verify
> > WARNING: Actual Digest: uGqjmTDx7IDyniF7hh5eaQ2ZWjU=
> I've taken the message and verified it successfully with a number of XML
> signature implementations, including the Apache one at
> https://svn.apache.org/repos/asf/xml/security/tags/J_1_4_2, which is the
> version that rampart actually uses (i.e. xmlsec-1.4.2.jar ships with Rampart
> 1.5).
> The attached file correct.dat is the c14n'd form of the body such that
> SHA1(correct.dat) matches the digest in the signature:
> > $ openssl sha1 -binary correct.dat | openssl base64
> > uf7xYFDKnUgQgxBg3SJTSIY/osk=
> You can see that this digest matches the "Expected Digest" in the Rampart
> trace above, which is the digest in the XML Signature.
> The attached file incorrect.dat is the data as passed to the digest via
> rampart:
> > $ openssl sha1 -binary incorrect.dat | openssl base64
> > uGqjmTDx7IDyniF7hh5eaQ2ZWjU=
> You can see that this digest matches the "Actual Digest" produced by Rampart
> in the trace above.
> The differences between the two inputs looks as follows:
> >
> > --- correct.dat 2010-07-26 11:08:54.000000000 +0100
> > +++ incorrect.dat 2010-07-26 11:08:54.000000000 +0100
> > @@ -1,8 +1,8 @@
> > <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> >
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd"
> > wsu:Id="Id-0000012a0e1a1572-00000000010a6723-3">
> > <GetDirectionsResponse xmlns="http://www.ecubicle.net/webservices/";>
> > <GetDirectionsResult>
> > - <drivingdirections xmlns="">
> > - <route distanceToTravel=" 500 m" finalStep="false" id="0">
> > + <drivingdirections>
> > + <route>
> > Head south on Grove St
> > </route>
> > <totalDistance>739 km</totalDistance>
> You can see that rampart has dropped the xmlns="" attribute/namespace
> declaration from the "drivingdirections" element, and also the attributes
> from the route element (indeed, it seems that neither the attribute or
> namespace axes have been entirely eliminated).
> Experimentation shows that naiively deleting the default namespace
> declaration (i.e. xmlns="") from the drivingdirections element actually
> produces a signature that rampart can verify, so it is not just
> systematically eliminating theses axes.
> This bug seems to resemble Issue 128, but this was logged in December 2007
> for Rampart 1.3 and is still open. And since i had a bit more information I
> thought I'd add it in as a new issue.
> https://issues.apache.org/jira/browse/RAMPART-128
> You can see an example of a Web Service that returns elements in the empty
> namespace (i.e. xmlns="") here:
> http://www.ecubicle.net/driving.asmx?wsdl
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
