Open glassfishrobot opened 16 years ago
Reported by capsicum@java.net
ashutoshshahi@java.net said: Yes please, attach a reproducible testcase if you can, and also the stacktrace that you are seeing.
Ashutosh
ashutoshshahi@java.net said: Setting target milestone to 1.4
ashutoshshahi@java.net said: marking as started
capsicum@java.net said: I'm working on a repro.
capsicum@java.net said: The stack trace I am seeing is this:
javax.xml.crypto.dsig.XMLSignatureException: WSS1717: Error occurred while doing digest verification of body/payload javax.xml.ws.WebServiceException: javax.xml.crypto.dsig.XMLSignatureException: WSS1717: Error occurred while doing digest verification of body/payload at com.sun.xml.ws.security.opt.impl.incoming.processor.StreamingPayLoadDigester.accept(StreamingPayLoadDigester.java:89) at com.ctc.wstx.stax.FilteredStreamReader.next(FilteredStreamReader.java:45) at com.sun.xml.ws.security.opt.impl.util.VerifiedMessageXMLStreamReader.next(VerifiedMessageXMLStreamReader.java:68) at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.storeElementAndChildrenNoEx(StreamReaderBufferCreator.java:245) at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.storeElementAndChildren(StreamReaderBufferCreator.java:177) at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.store(StreamReaderBufferCreator.java:142) at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.create(StreamReaderBufferCreator.java:82) at com.sun.xml.stream.buffer.MutableXMLStreamBuffer.createFromXMLStreamReader(MutableXMLStreamBuffer.java:113) at com.sun.xml.ws.security.opt.impl.incoming.VerifiedStreamMessage.cacheMessage(VerifiedStreamMessage.java:513) at com.sun.xml.ws.security.opt.impl.incoming.VerifiedStreamMessage.readPayloadAsJAXB(VerifiedStreamMessage.java:259) at com.sun.xml.ws.client.sei.ResponseBuilder$Body.readResponse(ResponseBuilder.java:469) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:121) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89) at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118) <... My application code here ...> Caused by: javax.xml.crypto.dsig.XMLSignatureException: WSS1717: Error occurred while doing digest verification of body/payload at com.sun.xml.ws.security.opt.impl.incoming.processor.StreamingPayLoadDigester.accept(StreamingPayLoadDigester.java:88) ... 46 more
I am having trouble isolating it to a small test case. I'll keep working on it.
capsicum@java.net said: Created an attachment (id=670) Testcase which reproduces the bug
capsicum@java.net said: I uploaded a testcase which reproduces it. It took quite a lot of effort to extract a smallish test case from the full application. I ended up with this peculiar case, which I was not able to reduce further.
The test case consists of a simple web service built on a WSDL which has been customized with JAXB dom bindings. I have duplicated the service so there are secure and plain variants of it.
The WSDL has been written by hand and I have put the WS-SecurityPolicies in it by hand, though they have been generated by Netbeans. I think they are right since the security works if I simplify the schema of the messages being passed.
I am using a server certificate and the client authenticates with username/password.
You must set the metro.home in the ant build file.
You also need to modify the keystore location in the client wsit configuration, shello-client.xml.
-Finally you must adjust the client username and password in the callback class so it presents a valid login to your glassfish installation.
To build the plain WAR run "ant war". This produces "hello.war" in "build". Deploy it in glassfish.
To build the secure WAR run "ant secure-war". Deploy "securehello.war".
To run the plain client do "ant run-client".
To run the secure client do "ant run-secureclient"
When the secure service is invoked, I get the exception from the integrity check.
Strangely enough this test case seems to trigger some other bugs in jaxb. (Or am I doing something wrong?) In the plain invocation, the two parts of the message get mixed up and one part is lost. I have seen this behaviour previously, but in the full application where I had a problem with the security failing, I didn't have this mixed up messages issue if I used a plain service. And if you try to simplified the schemas slightly, the security will start working, but the message parts still get mixed up.
I suspect that the bugs are in JAXB rather than WSIT, but I am not sure.
I am running on Linux, but I have reproduced it on Windows as well. (In the full application. I haven't tried the test case on windows.)
I am using the "official" metro 1.2 binaries and Java 6.
Sometimes I get a warning message like this:
[wsimport] [WARNING] src-resolve: Cannot resolve the name 'hemsg:Message' to
a 'element declaration' component.
[wsimport] line 46 of file:...testcase/hello.wsdl#types?schema2
Strangely enough whether I get this message or not depends on the full file path and name of the WSDL. When I packed up the zip-file to test it before I uploaded it here, I ran it in the directory called "testcase" which is included in the zip. I got the above warning. If I renamed the directory to "t4", I didn't get the warning. The code seems to work the same though regardless of this.
Another issue, which is perhaps a separate bug in JAXB?, is that the message content is modified in transit. Lots of namespace prefix declarations are added and the indentation is changed. The content is still the "same", but since namespace declarations are significant in typical XML signatures, this behavior would ruin any signatures I might be using at the application layer. I initially thought that this was the reason of the integrity check failure, but with a simplified schema I still get the modified content, but security works.
ashutoshshahi@java.net said: Hello, Thanks for the testcase. I tried the testcase with latest 1.3 nightly and it is working fine for me. Can you try with the nightly build and see if the issues have been fixed.
Ashutosh
capsicum@java.net said: I tried the 1.3 nightly and I get the same error as before:
run-secureclient: [echo] Running the secure client [java] Jul 14, 2008 12:42:34 PM [com.sun.xml.ws.policy.jaxws.PolicyConfigParser] parse [java] INFO: WSP1049: Loaded WSIT configuration from file: jar:file:/home/erik/workspace/MetroBugRepro/build/secureclient.jar!/META-INF/wsit-client.xml [java] Jul 14, 2008 12:42:39 PM com.sun.xml.ws.security.opt.impl.incoming.processor.StreamingPayLoadDigester accept [java] SEVERE: WSS1717: Error occurred while doing digest verification of body/payload [java] Exception in thread "main" javax.xml.ws.WebServiceException: javax.xml.crypto.dsig.XMLSignatureException: WSS1717: Error occurred while doing digest verification of body/payload [java] at com.sun.xml.ws.security.opt.impl.incoming.processor.StreamingPayLoadDigester.accept(StreamingPayLoadDigester.java:103) [java] at com.ctc.wstx.stax.FilteredStreamReader.next(FilteredStreamReader.java:45) [java] at com.sun.xml.ws.security.opt.impl.util.VerifiedMessageXMLStreamReader.next(VerifiedMessageXMLStreamReader.java:82) [java] at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.storeElementAndChildrenNoEx(StreamReaderBufferCreator.java:245) [java] at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.storeElementAndChildren(StreamReaderBufferCreator.java:177) [java] at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.store(StreamReaderBufferCreator.java:142) [java] at com.sun.xml.stream.buffer.stax.StreamReaderBufferCreator.create(StreamReaderBufferCreator.java:82) [java] at com.sun.xml.stream.buffer.MutableXMLStreamBuffer.createFromXMLStreamReader(MutableXMLStreamBuffer.java:113) [java] at com.sun.xml.ws.security.opt.impl.incoming.VerifiedStreamMessage.cacheMessage(VerifiedStreamMessage.java:527) [java] at com.sun.xml.ws.security.opt.impl.incoming.VerifiedStreamMessage.readPayload(VerifiedStreamMessage.java:292) [java] at com.sun.xml.ws.client.sei.ResponseBuilder$DocLit.readResponse(ResponseBuilder.java:523) [java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:121) [java] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89) [java] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118) [java] at $Proxy44.hello(Unknown Source) [java] at com.example.hello.client.SecureHelloClient.main(SecureHelloClient.java:26) [java] Caused by: javax.xml.crypto.dsig.XMLSignatureException: WSS1717: Error occurred while doing digest verification of body/payload [java] at com.sun.xml.ws.security.opt.impl.incoming.processor.StreamingPayLoadDigester.accept(StreamingPayLoadDigester.java:102) [java] ... 15 more [java] Java Result: 1
My java:
$ java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode)
I am using glassfish "glassfish-installer-v2ur2-b04-linux.jar"
And as I said, I have had the same issue on Windows as well. (I don't remember exact versions of java and glassfish then.)
What more can I do to help you out?
One thing I was thinking about doing is to modify metro so it writes the canonicalized XML to a couple of files, so I can see what has changed between the signature generation and signature verification. I downloaded the metro source, but it was not immediately obvious to me how to do the modification. Large parts of the source consisted of zipped distributions of other code, so I gave up on that then. If you would think that this would be helpful, let me know, and advise me to where the signature is generated and verified in the metro source.
ashutoshshahi@java.net said: I tried the sample with both JDK 5 and 6, and it worked for me. Security sources are from xwss project. You can check out the sources from xwss.dev.java.net.
If any extra namespaces are added in the xml and they are unused, they will be removed during canonicalization, before signature verification, so it should not matter.
Ashutosh
capsicum@java.net said: Hello again. I modified the xwss jar so it writes the canonicalized XML to files in /tmp which I then had a look at. It looks like it is added namespace declarations which are braking the signature. Here are two of the files which were created, which I suspect should be identical:
First file:
<S:Body xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="_5006"><ns3:HelloResponse
xmlns:ns3="http://example.com/helloService/hello"><ns2:Message
xmlns:ns2="http://example.com/helloService/hellomsg">
ashutoshshahi@java.net said: target for 1.5 release
kumarjayanti@java.net said: reassign
m_potociar@java.net said: Assigning to Kumar and downgrading to P4. We will try to revisit the issue after Metro 2.0 release.
File: testcase.zip Attached By: capsicum@java.net
This issue was imported from java.net JIRA WSIT-960
Using jaxb DOM binding makes security fail. By looking at the stack trace and the Metro source code I can see that it's the message integrity check which fails. I suspect this is because jaxb (or something else?) rewrites namespace prefixes and adds namespace declarations in the message in transit. I can see these changes if I do not use security. For instance, if I send a DOM node such as this in a message:
when I receive it will look something like this:
<ns1:foo xmlns:ns1="http://example.com/someSchema" xmlsns:ns2="http://some.another.namespace.here/2" xmlsns:ns3="http://some.another.namespace.here/3">