To make things even more complicated, if I use our own jetty transport in a "main method" standalone fashion, it also works fine. :-(
Dan On Wednesday, June 01, 2011 4:38:32 PM Daniel Kulp wrote: > On Wednesday, June 01, 2011 2:54:44 PM Ross Lodge wrote: > > Ok; I can confirm it works correctly with tomcat 7 as well, at least as > > executed through the cargo maven2 plugin. Still fails in the latest > > Jetty M3 version. > > I think I'm going to need to defer to Colm on this one. I've gone > through the WSS4J code and right before calling the line: > > signatureOk = xmlSignature.validate(context); > > if I print the DOM of the header, it's completely correct exactly like what > came in. However, immediately after, it's completely changed. For > example, I turned off the encryption in your testcase so its just > signatures. With your system-id header. Before: > > <ns2:system-identifier > xmlns:ns2="http://www.example.org/schema/DoubleIt"; > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur > ity-utility-1.0.xsd" > wsu:Id="Id-297842848">test-client</ns2:system-identifier> > > after: > > <ns2:system-identifier > wsu:Id="Id-297842848" > xmlns="" > xmlns:ns2="http://www.example.org/schema/DoubleIt"; > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur > ity-utility-1.0.xsd">test-client</ns2:system-identifier> > > I'm not sure why the "" and soap namespaces are being added to it or where > that would be occurring. It's pretty strange. It all works OK in > Tomcat. Before and after are exactly the same. > > > Dan > > > Ross > > > > On Wed, Jun 1, 2011 at 10:32 AM, Daniel Kulp <[email protected]> wrote: > > > This seems to be a problem specific to Jetty. I'm not sure what's > > > happening > > > with it yet. However, if I take the war and drop it into a "virgin" > > > Tomcat 6 > > > install, the "mvn exec:exec" in the client dir runs fine. Also if I > > > run "mvn tomcat:run" in the service war and update the URL's in the > > > client project > > > to the new location > > > (http://localhost:8080/service-war/services/doubleit) then > > > it also runs fine. Thus, it does look like it's some sort of conflict > > > with > > > Jetty. I'm just not sure what yet. > > > > > > Dan > > > > > > On Tuesday, May 31, 2011 7:41:08 PM Ross Lodge wrote: > > > > I've been trying to get the new 2.4.0 release to work in a project > > > > that > > > > > > I'm > > > > > > > using that uses WS-Security and WS-SecurityPolicy in a WSDL-First > > > > SOAP service, and I am getting a signature verification failure: > > > > > > > > Caused by: org.apache.ws.security.WSSecurityException: The signature > > > > or > > > > > > > > > decryption was invalid; nested exception is: > > > > > > > > > > org.apache.ws.security.WSSecurityException: The signature or > > > > > decryption was invalid > > > > > > > > > > at > > > > > > org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature( > > > Si > > > > > > > > gnatureProcessor.java:378) ~[wss4j-1.6.0.jar:1.6.0] > > > > > > > > > > at > > > > > > org.apache.ws.security.processor.SignatureProcessor.handleToken(Signatu > > > re > > > > > > > > Processor.java:174) ~[wss4j-1.6.0.jar:1.6.0] > > > > > > > > > > at > > > > > > org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurit > > > yE > > > > > > > > ngine.java:396) ~[wss4j-1.6.0.jar:1.6.0] > > > > > > > > > > at > > > > > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4J > > > In > > > > > > > > Interceptor.java:248) ~[cxf-rt-ws-security-2.4.0.jar:2.4.0] > > > > > > > > > > ... 35 common frames omitted > > > > > > > > > > Caused by: org.apache.ws.security.WSSecurityException: The > > > > > signature or decryption was invalid > > > > > > > > > > at > > > > > > org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature( > > > Si > > > > > > > > gnatureProcessor.java:375) ~[wss4j-1.6.0.jar:1.6.0] > > > > > > > > > > ... 38 common frames omitted > > > > > > > > It's quite possible that I'm missing something (e.g. relating to how > > > > > > WSS4J > > > > > > > 1.6 needs to be configured vs WSSJ 1.5, for instance), or this could > > > > be a bug of some kind. > > > > > > > > Any help would be appreciated; I've uploaded sample code that > > > > exhibits > > > > > > this > > > > > > > problem to: > > > http://software-entropy.com/wp-content/uploads/2011/05/ws-security-bug. > > > 2. 3 . > > > > > > > 4.zip > > > > > > http://software-entropy.com/wp-content/uploads/2011/05/ws-security-bug. > > > 2. 4 > > > > > > > .0.zip > > > > > > > > Both of these are simple maven projects based on Glen Mazza's > > > > blog-posts about how to build a WS-Security-enabled service with CXF. > > > > You'll need > > > > > > to > > > > > > > do a "mvn clean install" from the parent module and then first a "mvn > > > > jetty:run" (or deploy the war to your favorite container) in the > > > > service-war module and, while it's running, a "mvn exec:exec" in the > > > > client module. For me, this works fine for the 2.3.4 version of the > > > > > > code, > > > > > > > but fails for the 2.4.0 version of the code; everything aside from > > > > the > > > > > > CXF > > > > > > > dependency version is the same between the two zip files. > > > > > > > > Thanks. > > > > > > > > (yes, this is a repost, with a different and potentially > > > > easier-to-use example; I've been unable to find a solution for > > > > this). > > > > > > > > Ross M. Lodge > > > > > > -- > > > Daniel Kulp > > > [email protected] > > > http://dankulp.com/blog > > > Talend - http://www.talend.com -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
