[
https://issues.apache.org/jira/browse/RAMPART-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893126#action_12893126
]
Niall Tierney commented on RAMPART-303:
---------------------------------------
Hey Amila - thanks for the fast reply.
I think the error you are seeing is because you are not sending up the method
parameters in the correct format. Unfortunately the Web Service schema does not
have a restriction on the type of these params (just uses xsd:string) so I only
found out the expected format from the Web Service info page at
http://www.ecubicle.net/driving.asmx. You can see the expected format in the
attached DrivingClient.java file.
Anyway, just to be clear, here's the steps you can follow to quickly create a
client for this Web Service:
1. %AXIS2_HOME%\bin\wsdl2java -uri http://www.ecubicle.net/driving.asmx?wsdl
-p driving.client -uw
This generates2 classes in the specified "driving.client" package:
driving.client.DrivingStub.java
driving.client.DrivingCallbackHandler.java
2. Create driving.client.DrivingClient.java with the code in the attached
DrivingClient.java source file.
3. Run the ant build file that was auto-generated by wsdl2java in your
WORKING_DIR.
4. Add [WORKING_DIR]/build/lib/driving-test-client.jar to the classpath
5. java driving.client.DrivingClient
6. The method response will be printed out to the console. Note that the
serialized XML contains the <drivingdirections> element with the xmlns=""
stripped out. However, this is ok in the context of the serialized XML since
the <drivingdirections> element is the root node and therefore, it is not
overriding any namespaces as is the case in the attached input.xml ... where it
is overriding the namespace on the <GetDirectionsResponse> element.
Anyway, these steps will allow you to invoke the Web Service with NO security.
To invoke security, you need to invoke Rampart, which i'm sure you know - I
followed the steps from the Rampart site here:
http://wso2.org/library/3415#securing_the_client
In terms of security, I have an XML Gateway product that virtualizes the public
GetDirections Web Service. It allows me to attach a WS-Policy to the
virtualized service on the Gateway. I can then point the wsdl2java tool at the
virtualized service definition (which now contains the WS-Policy) on the
Gateawy and that's how the client gets the security information.
I suppose to completely replicate the problem you may need to copy the WSDL
locally and attach the WS-Policy to it and then point wsdl2java at this WSDL.
At least them, Rampart will secure the request in the correct manner. However
you will still have to configure something to sign the response from the Web
Service. In my case, the XML Gateway i am using is doing this.
You can always use openssl commands as described earlier to sign the response
message (as given in the attached input.xml) and produce the digests - you
don't need to invoke the Web Service to replicate this - you can simply run the
openssl commands to verify.
I will attach the WSDL for the ecubicle WSDL with this WS-Policy attached to it
for your convenience.
Hope this helps,
Niall.
> 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.
