Hi Ross, Could you check the following scenarios:
CXF 2.3 client -> CXF 2.4 service CXF 2.4 client -> CXF 2.3 service I had thought initially that maybe the inclusive namespace prefix stuff added to WSS4 1.6 might be causing it, but I turned it off and that's not the problem. I suspect the problem is on the inbound side in CXF 2.4, and so I would expect the first scenario above to fail, but the second to pass. Colm. On Wed, Jun 1, 2011 at 9:52 PM, Daniel Kulp <[email protected]> wrote: > > 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 > -- Colm O hEigeartaigh http://coheigea.blogspot.com/ Talend - http://www.talend.com
