axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doughty, Michael" <Michael_Doug...@bmc.com>
Subject RE: Signature verification fails when signing the Body
Date Thu, 15 Oct 2009 11:08:13 GMT
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?

Mime
View raw message