Are you asking for the entire MSVC project? Or are you asking for just the source files?
-----Original Message----- From: Selvaratnam Uthaiyashankar [mailto:uthaiyashan...@gmail.com] Sent: Thursday, October 15, 2009 10:25 PM To: Apache AXIS C User List Subject: Re: Signature verification fails when signing the Body Hi, Can you send the client code? Regards, Shankar On Thu, Oct 15, 2009 at 4:38 PM, Doughty, Michael <michael_doug...@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_doug...@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"
