axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selvaratnam Uthaiyashankar <uthaiyashan...@gmail.com>
Subject Re: Signature verification fails when signing the Body
Date Fri, 16 Oct 2009 03:25:27 GMT
Hi,

Can you send the client code?

Regards,
Shankar

On Thu, Oct 15, 2009 at 4:38 PM, Doughty, Michael
<Michael_Doughty@bmc.com> wrote:
> Just a follow-up here on the problem.  I did a bit of searching around on
> this and I found the following from a user having almost exactly the same
> issue about a year ago:
>
>
>
> http://marc.info/?l=axis-c-user&m=122333172329075&w=2
>
>
>
> The problem is that it ended without a reply showing a resolution, so it
> didn’t really help me understand what is going on or how to possibly fix the
> issue.
>
>
>
> I wanted to validate that this same condition occurred when I used different
> client and server-side asymmetric keys, so I’ve created new private key and
> certificates for client and server side, and reproduced the problem with
> signature-only since it seems to be only the signing mechanism that is
> failing.
>
>
>
> I ran for three separate conditions:
>
>
>
> (1)  Signing both the Body and UsernameToken
>
> (2)  Signing only the Body
>
> (3)  Signing only the UsernameToken
>
>
>
> I ran the test using both Rampart/C with Axis/C and WSS4J in a testing
> tool.  The WSS4J signatures all work properly with the keys and certs I’ve
> included after they were stored away in JKS files.  Rampart/C messages fail
> signature checking however whenever the Body is signed, so scenarios 1 and 2
> fail, while scenario 3 works fine despite a signature being applied to
> UsernameToken.
>
>
>
> I’ve attached a zip file containing the requests through Rampart/C and
> WSS4J, the policy files I used for Rampart/C, the PEM files I used for
> Rampart/C, and the JKS files I used for WSS4J.  The keys are non-production
> testing keys I created specifically for this.  The directory structure is as
> follows:
>
>
>
> PEM files:
>
> pem-files\server.cer – Server’s public key in PEM format
>
> pem-files\server.pem – Server’s private key in PEM format
>
> pem-files\client.cer – Client’s public key in PEM format
>
> pem-files\client.pem – Client’s private key in PEM format
>
>
>
> JKS files:
>
> jks-files\server.jks – Server’s JKS keystore file.  The keystore password is
> “testing”, the alias is “server”, and the key password is “testing”.
>
> jks-files\server.jks – Client’s JKS keystore file.  The keystore password is
> “testing”, the alias is “client”, and the key password is “testing”.
>
>
>
> Rampart/C Client Policy files:
>
> rampartc-policy\SIGN-BODY-AND-UT.policy.xml - Signs the SOAP:Body and
> wsse:UsernameToken
>
> rampartc-policy\SIGN-BODY-ONLY.policy.xml - Signs only the SOAP:Body
>
> rampartc-policy\SIGN-UT-ONLY.policy.xml - Signs only the wsse:UsernameToken
>
>
>
> Rampart/C Client Requests:
>
> rampartc-requests\SIGN-BODY-AND-UT.request.xml - Request with both SOAP:Body
> and wsse:UsernameToken signed - FAILS validation
>
> rampartc-requests\SIGN-BODY-ONLY.request.xml - Request with only the
> SOAP:Body signed - FAILS validation
>
> rampartc-requests\SIGN-UT-ONLY.request.xml - Request with only the
> wsse:UsernameToken signed - PASSES validation
>
>
>
> WSS4J Client Requests:
>
> wss4j-requests\SIGN-BODY-AND-UT.request.xml - Request with both SOAP:Body
> and wsse:UsernameToken signed - PASSES validation
>
> wss4j-requests\SIGN-BODY-ONLY.request.xml - Request with only the SOAP:Body
> signed - PASSES validation
>
> wss4j-requests\SIGN-UT-ONLY.request.xml - Request with only the
> wsse:UsernameToken signed - PASSES validation
>
>
>
> If someone knowledgeable about this could spare some time to help me out on
> the subject, I’d appreciate it.  We are kind of up against a tree on this
> one.
>
>
>
> ________________________________
>
> From: Doughty, Michael [mailto:Michael_Doughty@bmc.com]
> Sent: Wednesday, October 14, 2009 12:11 AM
> To: Apache AXIS C User List
> Subject: Signature verification fails when signing the Body
>
>
>
> I am trying to write a client to consume a set of about 15 Web services
> secured by an implementation of the WS-Security 1.0 standard.  These Web
> services require a usernametoken, that the content of the body be signed and
> encrypted, and that the entire usernametoken element be encrypted as well.
>
>
>
> Normally we use Axis2 and Rampart for Java, but in this case we are
> constrained to using C, and because other tools like gSoap don’t support XML
> encryption, we decided on using Axis2/C and Rampart/C.
>
>
>
> The problem is that something isn’t quite working right on the signing of
> the content.  When I perform the operation with the policy.xml file set to
> do these tasks, the Web service complains and fails with the following
> message: “An error occured while processing the message security header:
> Signature verification failed”.
>
>
>
> This has perplexed me for a while, because the other tools I’ve been using
> seem to work properly.  I’ve written clients in Systinet Server for Java
> using their WS-Security implementation, Axis2/Rampart for Java, and
>  Axis/WSS4J implementation, all of which work properly.
>
>
>
> I took a look at the fault message that was returned to the Axis2/C client,
> as it included a Java exception stack, and I see that the Web services are
> using an implementation of security by Amberpoint along with Entrust
> security libraries.  So I decided to make sure this was not an
> implementation issue with those tools.  I created a fake service from one of
> the services’ WSDL files using a testing tool I have which uses WSS4J as its
> WS-Security implementation.  The fake service returns a similar error:
> “org.apache.wss4j11.security.WSSecurityException: The signature verification
> failed.”
>
>
>
> Since I can’t change the security policies of the real Web services, I
> decided to see what would happen if I made the signature and encryption
> optional in my faked out service and then played around with the options in
> my Axis2/C and Rampart/C based client’s policy.xml file.  It turns out that
> everything works fine except when I try to sign the body.  It is when I sign
> the body that the signature fails.  Ironically, if I sign other content in
> the header, such as the UsernameToken, the signature checking passes
> validation on my faked out service, while the real services complain that
> the Body isn’t signed when it is required to be.
>
>
>
> Is this a known issue?  I am using the 1.3.0 release.  Is there any way to
> work around it that won’t require me to change security policies on the
> services I am trying to consume?



-- 
S.Uthaiyashankar
Software Architect
WSO2 Inc.
http://wso2.com/ - "The Open Source SOA Company"

Mime
View raw message