You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ross Lodge <ro...@concentricsky.com> on 2011/06/01 01:41:08 UTC
Problem with WS-Security and CXF 2.4.0
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(SignatureProcessor.java:378)
> ~[wss4j-1.6.0.jar:1.6.0]
>
> at
> org.apache.ws.security.processor.SignatureProcessor.handleToken(SignatureProcessor.java:174)
> ~[wss4j-1.6.0.jar:1.6.0]
>
> at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)
> ~[wss4j-1.6.0.jar:1.6.0]
>
> at
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.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(SignatureProcessor.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
Re: Problem with WS-Security and CXF 2.4.0
Posted by Ross Lodge <ro...@concentricsky.com>.
That doesn't *appear* to be the problem; neither switching to the latest
2.4.1-SNAPSHOT nor removing any handlers I had added seems to make a
difference.
Ross
On Wed, Jun 1, 2011 at 3:03 AM, Dirk Rudolph <Dirk.Rudolph@t-systems-mms.com
> wrote:
> I also had problems porting a cxf 2.3.3 webservice using ws-security to cxf
> 2.4.0. Maybe the solution provided for my issue also solves your problem.
>
> Have a look at https://issues.apache.org/jira/browse/CXF-3514 and try the
> CXF 2.4.1-SNAPSHOT.
>
> Dirk Rudolph
>
> -----Ursprüngliche Nachricht-----
> Von: Ross Lodge [mailto:ross.lodge@concentricsky.com]
> Gesendet: Mittwoch, 1. Juni 2011 01:41
> An: users@cxf.apache.org
> Betreff: Problem with WS-Security and CXF 2.4.0
>
> 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(Signa
> tureProcessor.java:378)
> > ~[wss4j-1.6.0.jar:1.6.0]
> >
> > at
> >
>
> org.apache.ws.security.processor.SignatureProcessor.handleToken(SignaturePro
> cessor.java:174)
> > ~[wss4j-1.6.0.jar:1.6.0]
> >
> > at
> >
>
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngi
> ne.java:396)
> > ~[wss4j-1.6.0.jar:1.6.0]
> >
> > at
> >
>
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInt
> erceptor.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(Signa
> tureProcessor.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
>
>
AW: Problem with WS-Security and CXF 2.4.0
Posted by Dirk Rudolph <Di...@t-systems-mms.com>.
I also had problems porting a cxf 2.3.3 webservice using ws-security to cxf
2.4.0. Maybe the solution provided for my issue also solves your problem.
Have a look at https://issues.apache.org/jira/browse/CXF-3514 and try the
CXF 2.4.1-SNAPSHOT.
Dirk Rudolph
-----Ursprüngliche Nachricht-----
Von: Ross Lodge [mailto:ross.lodge@concentricsky.com]
Gesendet: Mittwoch, 1. Juni 2011 01:41
An: users@cxf.apache.org
Betreff: Problem with WS-Security and CXF 2.4.0
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(Signa
tureProcessor.java:378)
> ~[wss4j-1.6.0.jar:1.6.0]
>
> at
>
org.apache.ws.security.processor.SignatureProcessor.handleToken(SignaturePro
cessor.java:174)
> ~[wss4j-1.6.0.jar:1.6.0]
>
> at
>
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngi
ne.java:396)
> ~[wss4j-1.6.0.jar:1.6.0]
>
> at
>
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInt
erceptor.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(Signa
tureProcessor.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
Re: Problem with WS-Security and CXF 2.4.0
Posted by Colm O hEigeartaigh <co...@apache.org>.
This is now fixed in WSS4J 1.6.2-SNAPSHOT. You can test via the jar
attached here:
https://issues.apache.org/jira/secure/attachment/12487842/wss4j-1.6.2-SNAPSHOT.jar
Colm.
On Thu, Jul 7, 2011 at 10:15 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday, July 07, 2011 6:20:39 AM mickysantomax wrote:
>> Hi, I tried to embed my code in CXF wssec example and it works.
>>
>> You can see it attached here:
>> http://cxf.547215.n5.nabble.com/file/n4561032/apache-cxf-2.4.0-samples.zip
>> apache-cxf-2.4.0-samples.zip
>>
>> You can run client and server into 2 different shell that point to the path
>> /./ws_security/sign_enc/ and executing /ant client/ and /ant server/
>>
>> Just a simple question, CXF samples like this that I have modified doesn't
>> run in Jetty container ?
>
> Jetty is doing SOMETHING funky with either a classloader or a system property
> or security configs or something that is causing some issues. In Jetty,
> for some reason, when validating the signatures, the passed in DOM (which
> should only be read) is being modified. Colm is looking into it, but we
> have no idea what is going on right now. It only occurs in Jetty, and only
> with the full Jetty container, not using our embedded Jetty transport or even
> if we setup the Jetty context stuff ourselves like we do in our tests.
>
> Dan
>
>
>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp44
>> 43698p4561032.html Sent from the cxf-user mailing list archive at
>> Nabble.com.
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
--
Colm O hEigeartaigh
http://coheigea.blogspot.com/
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, July 07, 2011 6:20:39 AM mickysantomax wrote:
> Hi, I tried to embed my code in CXF wssec example and it works.
>
> You can see it attached here:
> http://cxf.547215.n5.nabble.com/file/n4561032/apache-cxf-2.4.0-samples.zip
> apache-cxf-2.4.0-samples.zip
>
> You can run client and server into 2 different shell that point to the path
> /./ws_security/sign_enc/ and executing /ant client/ and /ant server/
>
> Just a simple question, CXF samples like this that I have modified doesn't
> run in Jetty container ?
Jetty is doing SOMETHING funky with either a classloader or a system property
or security configs or something that is causing some issues. In Jetty,
for some reason, when validating the signatures, the passed in DOM (which
should only be read) is being modified. Colm is looking into it, but we
have no idea what is going on right now. It only occurs in Jetty, and only
with the full Jetty container, not using our embedded Jetty transport or even
if we setup the Jetty context stuff ourselves like we do in our tests.
Dan
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp44
> 43698p4561032.html Sent from the cxf-user mailing list archive at
> Nabble.com.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by Glen Mazza <gm...@talend.com>.
You can place your web service in a WAR and deploy to any servlet
container: http://www.jroller.com/gmazza/entry/web_service_tutorial
shows an example, also look here:
http://www.jroller.com/gmazza/entry/blog_article_index for some security
examples.
HTH,
Glen
On 07/07/2011 09:20 AM, mickysantomax wrote:
> Hi, I tried to embed my code in CXF wssec example and it works.
>
> You can see it attached here:
> http://cxf.547215.n5.nabble.com/file/n4561032/apache-cxf-2.4.0-samples.zip
> apache-cxf-2.4.0-samples.zip
>
> You can run client and server into 2 different shell that point to the path
> /./ws_security/sign_enc/ and executing /ant client/ and /ant server/
>
> Just a simple question, CXF samples like this that I have modified doesn't
> run in Jetty container ?
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4561032.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza
Re: Problem with WS-Security and CXF 2.4.0
Posted by mickysantomax <mi...@tiscali.it>.
Hi, I tried to embed my code in CXF wssec example and it works.
You can see it attached here:
http://cxf.547215.n5.nabble.com/file/n4561032/apache-cxf-2.4.0-samples.zip
apache-cxf-2.4.0-samples.zip
You can run client and server into 2 different shell that point to the path
/./ws_security/sign_enc/ and executing /ant client/ and /ant server/
Just a simple question, CXF samples like this that I have modified doesn't
run in Jetty container ?
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4561032.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with WS-Security and CXF 2.4.0
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
The BouncyCastle exception is not a problem, it's just a message that
the BouncyCastle jar (which is optional) is not being used. If it's
not working with Jetty, and is working with Tomcat, then it sounds
like the previous problem, which I have not yet gotten to the bottom
of. Can you please confirm that the testcase still fails with JDK 1.5
on Jetty? If so, supplying the test-case would be great, as I'm having
difficulty debugging the other issue due to the fact the signature
verification code is in the JDK, and it works with JDK 1.5.
Colm.
On Tue, Jul 5, 2011 at 6:18 PM, mickysantomax <mi...@tiscali.it> wrote:
> I use /slf4j/ as logger and set it to /trace/ level, but the log remain the
> same. If I copy only war file from my target dir after installation with
> maven (we can call it "original war file") in log there's a
> java.lang.ClassNotFoundException:
> org.bouncycastle.jce.provider.BouncyCastleProvider and after the
> org.apache.ws.security.WSSecurityException: The signature or decryption was
> invalid exception:
>
> http://cxf.547215.n5.nabble.com/file/n4554059/jettyLogWithoutBoucyCastleLib.log
> jettyLogWithoutBoucyCastleLib.log
>
> If I add manually jar of boucyCastle from cxf 2.3.3 (we can call it
> "modified war file") the java.lang.ClassNotFoundException:
> org.bouncycastle.jce.provider.BouncyCastleProvider error is not present but
> persist the org.apache.ws.security.WSSecurityException: The signature or
> decryption was invalid exception:
>
> http://cxf.547215.n5.nabble.com/file/n4554059/jettyLogWithBoucyCastleLib.log
> jettyLogWithBoucyCastleLib.log
>
> I tried also with /apache tomcat/ but problem doesn't occur. Below there's
> also an extraction of log of tomcat:
>
> 1 - ["original war file"])
> http://cxf.547215.n5.nabble.com/file/n4554059/tomcatLogWithoutBoucyCastleLib.log
> tomcatLogWithoutBoucyCastleLib.log
>
> 2 - ["modified war file"])
> http://cxf.547215.n5.nabble.com/file/n4554059/tomcatLogWithBoucyCastleLib.log
> tomcatLogWithBoucyCastleLib.log
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4554059.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
http://coheigea.blogspot.com/
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by mickysantomax <mi...@tiscali.it>.
I use /slf4j/ as logger and set it to /trace/ level, but the log remain the
same. If I copy only war file from my target dir after installation with
maven (we can call it "original war file") in log there's a
java.lang.ClassNotFoundException:
org.bouncycastle.jce.provider.BouncyCastleProvider and after the
org.apache.ws.security.WSSecurityException: The signature or decryption was
invalid exception:
http://cxf.547215.n5.nabble.com/file/n4554059/jettyLogWithoutBoucyCastleLib.log
jettyLogWithoutBoucyCastleLib.log
If I add manually jar of boucyCastle from cxf 2.3.3 (we can call it
"modified war file") the java.lang.ClassNotFoundException:
org.bouncycastle.jce.provider.BouncyCastleProvider error is not present but
persist the org.apache.ws.security.WSSecurityException: The signature or
decryption was invalid exception:
http://cxf.547215.n5.nabble.com/file/n4554059/jettyLogWithBoucyCastleLib.log
jettyLogWithBoucyCastleLib.log
I tried also with /apache tomcat/ but problem doesn't occur. Below there's
also an extraction of log of tomcat:
1 - ["original war file"])
http://cxf.547215.n5.nabble.com/file/n4554059/tomcatLogWithoutBoucyCastleLib.log
tomcatLogWithoutBoucyCastleLib.log
2 - ["modified war file"])
http://cxf.547215.n5.nabble.com/file/n4554059/tomcatLogWithBoucyCastleLib.log
tomcatLogWithBoucyCastleLib.log
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4554059.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with WS-Security and CXF 2.4.0
Posted by Colm O hEigeartaigh <co...@apache.org>.
Could you run the test again with Java logging level set to FINER and
post the debug log? Could you also supply a test-case if possible?
Colm.
On Fri, Jul 1, 2011 at 5:57 PM, mickysantomax <mi...@tiscali.it> wrote:
> I tried to run tests on Java 1.5 but error still remain the same: The
> signature or decryption was invalid
>
> as well as when I compiled with Java 1.6, there's the exception:
> java.lang.ClassNotFoundException:
> org.bouncycastle.jce.provider.BouncyCastleProvider
>
> See log attached:
> http://cxf.547215.n5.nabble.com/file/n4542731/logWithoutBouncyCastleProvider.log
> logWithoutBouncyCastleProvider.log
>
> But if I manually add it to the war the error persist
>
> See log attached:
> http://cxf.547215.n5.nabble.com/file/n4542731/logWithBouncyCastleProvider.log
> logWithBouncyCastleProvider.log
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4542731.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
http://coheigea.blogspot.com/
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by mickysantomax <mi...@tiscali.it>.
I tried to run tests on Java 1.5 but error still remain the same: The
signature or decryption was invalid
as well as when I compiled with Java 1.6, there's the exception:
java.lang.ClassNotFoundException:
org.bouncycastle.jce.provider.BouncyCastleProvider
See log attached:
http://cxf.547215.n5.nabble.com/file/n4542731/logWithoutBouncyCastleProvider.log
logWithoutBouncyCastleProvider.log
But if I manually add it to the war the error persist
See log attached:
http://cxf.547215.n5.nabble.com/file/n4542731/logWithBouncyCastleProvider.log
logWithBouncyCastleProvider.log
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4542731.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with WS-Security and CXF 2.4.0
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
This looks like the same bug that was previously reported using jetty.
I am doing some ongoing work on this issue - I have identified the
problem, but not why it's happening. It's most probably a bug in the
JDK 1.6 digital signature code. Could you try your testcase again
using JDK 1.5 and tell me if it works?
Colm.
On Thu, Jun 30, 2011 at 3:59 PM, mickysantomax <mi...@tiscali.it> wrote:
> I tried to run CXF examples coming with source distribution and all works
> fine.
>
> I tried to reproduce same example in my application (with same certificates,
> properties configuration files and so on) and have the error: "The signature
> or decryption was invalid".
>
> Tried with mixed scenarious:
>
> my CXF client and examples CXF service -> OK
> my CXF server and examples CXF client -> ERROR: "The signature or
> decryption was invalid".
>
> Tried with standalone Jetty server (versione 6.1.25). Initially there were a
> ClassNotFoundException (BouncyCastle), but after adding properly jar into
> classpath, the error persist.
>
> Below there's the log extracted from standalone Jetty server:
>
> http://pastebin.com/75GPqKax
>
> Thanks for your help.
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4539118.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
http://coheigea.blogspot.com/
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by mickysantomax <mi...@tiscali.it>.
Yes, because for running CXF samples I declared the CXF_HOME environment
variable in my system that point to apache-cxf-2.4.1 distribution that
contain wss4j-1.6.1.jar
For compiling my application I use maven and in .m2 repository there's only
wss4j-1.6.1.jar
Now I tried only to encrypt the message and all works fine, instead if I try
only to sign the message the error "Signature or Decryption was invalid"
occur.
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4549737.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with WS-Security and CXF 2.4.0
Posted by Glen Mazza <gm...@talend.com>.
Are you sure the WSS4J version hardcoded by the CXF tests, and the one
used inside your application, are the same?
Glen
On 07/01/2011 07:14 AM, mickysantomax wrote:
> Thank you Glen for your explanation, but if this is the reason, why if I run
> CXF tests all works well and if I put this test inside my application there
> are this problem ?
>
> I'm running this test:
>
> apache-cxf-2.4.0-samples\ws_security\sign_enc
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4541798.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza
Re: Problem with WS-Security and CXF 2.4.0
Posted by mickysantomax <mi...@tiscali.it>.
Thank you Glen for your explanation, but if this is the reason, why if I run
CXF tests all works well and if I put this test inside my application there
are this problem ?
I'm running this test:
apache-cxf-2.4.0-samples\ws_security\sign_enc
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4541798.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with WS-Security and CXF 2.4.0
Posted by Glen Mazza <gm...@talend.com>.
Keystore/truststore configuration has changed between CXF 2.3.x and
2.4.x due to the switch from WSS4J 1.5.x to 1.6.x. Please see here:
http://coheigea.blogspot.com/2011/01/wss4j-16-crypto-property-change.html for
more details.
HTH,
Glen
On 06/30/2011 10:59 AM, mickysantomax wrote:
> I tried to run CXF examples coming with source distribution and all works
> fine.
>
> I tried to reproduce same example in my application (with same certificates,
> properties configuration files and so on) and have the error: "The signature
> or decryption was invalid".
>
> Tried with mixed scenarious:
>
> my CXF client and examples CXF service -> OK
> my CXF server and examples CXF client -> ERROR: "The signature or
> decryption was invalid".
>
> Tried with standalone Jetty server (versione 6.1.25). Initially there were a
> ClassNotFoundException (BouncyCastle), but after adding properly jar into
> classpath, the error persist.
>
> Below there's the log extracted from standalone Jetty server:
>
> http://pastebin.com/75GPqKax
>
> Thanks for your help.
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4539118.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza
Re: Problem with WS-Security and CXF 2.4.0
Posted by mickysantomax <mi...@tiscali.it>.
I tried to run CXF examples coming with source distribution and all works
fine.
I tried to reproduce same example in my application (with same certificates,
properties configuration files and so on) and have the error: "The signature
or decryption was invalid".
Tried with mixed scenarious:
my CXF client and examples CXF service -> OK
my CXF server and examples CXF client -> ERROR: "The signature or
decryption was invalid".
Tried with standalone Jetty server (versione 6.1.25). Initially there were a
ClassNotFoundException (BouncyCastle), but after adding properly jar into
classpath, the error persist.
Below there's the log extracted from standalone Jetty server:
http://pastebin.com/75GPqKax
Thanks for your help.
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4539118.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with WS-Security and CXF 2.4.0
Posted by mickysantomax <mi...@tiscali.it>.
Hi all, I have similar problem.
When I use CXF 2.3.3 all works fine, but after switch to CXF 2.4.X when I
perform tests for my application I have the error: "The signature or
decryption was invalid".
Can anyone help me ?
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-WS-Security-and-CXF-2-4-0-tp4443698p4539092.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem with WS-Security and CXF 2.4.0
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <dk...@apache.org> 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 <dk...@apache.org> 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
>> > > dkulp@apache.org
>> > > http://dankulp.com/blog
>> > > Talend - http://www.talend.com
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
--
Colm O hEigeartaigh
http://coheigea.blogspot.com/
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by Daniel Kulp <dk...@apache.org>.
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 <dk...@apache.org> 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
> > > dkulp@apache.org
> > > http://dankulp.com/blog
> > > Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by Daniel Kulp <dk...@apache.org>.
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-wssecurity-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-wssecurity-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 <dk...@apache.org> 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(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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Problem with WS-Security and CXF 2.4.0
Posted by Ross Lodge <ro...@concentricsky.com>.
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.
Ross
On Wed, Jun 1, 2011 at 10:32 AM, Daniel Kulp <dk...@apache.org> 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(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
>
Re: Problem with WS-Security and CXF 2.4.0
Posted by Daniel Kulp <dk...@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