Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: users@cxf.apache.org
Subject: Re: Problem with WS-Security and CXF 2.4.0
Date: Wed, 1 Jun 2011 13:32:38 -0400
User-Agent: KMail/1.13.7 (Linux/2.6.39; KDE/4.6.3; x86_64; ; )
Cc: Ross Lodge <ross.lodge@concentricsky.com>
References: <BANLkTinvN90w7Y+cSyN+1PpQ-ZVCo9K9cQ@mail.gmail.com>
In-Reply-To: <BANLkTinvN90w7Y+cSyN+1PpQ-ZVCo9K9cQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201106011332.38674.dkulp@apache.org>


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(Signature
> > Processor.java:174) ~[wss4j-1.6.0.jar:1.6.0]
> > 
> > at
> > org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityE
> > ngine.java:396) ~[wss4j-1.6.0.jar:1.6.0]
> > 
> > at
> > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JIn
> > 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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com