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?
