[
https://issues.apache.org/jira/browse/RAMPART-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893107#action_12893107
]
Amila Jayasekara commented on RAMPART-303:
------------------------------------------
Hi Niall,
I am trying to reproduce this issue locally. I try to invoke example web
service that you mentioned above. (http://www.ecubicle.net/driving.asmx?wsdl ).
But end up with following exception,
Exception in thread "main" org.apache.axis2.AxisFault:
System.Web.Services.Protocols.SoapException: Server was unable to process
request. ---> System.NullReferenceException: Object reference not set to an
instance of an object.
at driving.GetDirections(String fromAddress, String toAddress, String
distanceUnit, String expresswayEnabled)
--- End of inner exception stack trace ---
at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:523)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:375)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at
org.apache.rampart.client.DrivingStub.getDirections(DrivingStub.java:187)
at org.apache.rampart.client.Client.main(Client.java:56)
It will be great if you could attach service code you used during this test.
Then i can reproduce this locally. Also i am not quite sure the way i called
your service is correct.
I generate code using wsdl2java and call stub as follows,
DrivingStub stub = new DrivingStub(ctx, args[0]);
stub.getDirections("address1", "address2", "50", "false");
Please give feedback. That will help me to reproduce this issue quickly.
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, 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.
