You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by "Doughty, Michael" <Mi...@bmc.com> on 2009/10/14 07:10:33 UTC
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?
RE: Signature verification fails when signing the Body
Posted by "Doughty, Michael" <Mi...@bmc.com>.
I've attached the main source file. But if you need the whole MSVC project file, let me know. I really appreciate your help.
-----Original Message-----
From: Doughty, Michael
Sent: Friday, October 16, 2009 9:27 AM
To: 'Apache AXIS C User List'
Subject: RE: Signature verification fails when signing the Body
Are you asking for the entire MSVC project? Or are you asking for just the source files?
-----Original Message-----
From: Selvaratnam Uthaiyashankar [mailto:uthaiyashankar@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
<Mi...@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"
Re: Signature verification fails when signing the Body
Posted by Selvaratnam Uthaiyashankar <ut...@gmail.com>.
I want to run and reproduce the problem. Just the source files are enough.
Regards,
Shankar
On Fri, Oct 16, 2009 at 7:56 PM, Doughty, Michael
<Mi...@bmc.com> wrote:
> Are you asking for the entire MSVC project? Or are you asking for just the source files?
>
> -----Original Message-----
> From: Selvaratnam Uthaiyashankar [mailto:uthaiyashankar@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
> <Mi...@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"
>
--
S.Uthaiyashankar
Software Architect
WSO2 Inc.
http://wso2.com/ - "The Open Source SOA Company"
RE: Signature verification fails when signing the Body
Posted by "Doughty, Michael" <Mi...@bmc.com>.
Are you asking for the entire MSVC project? Or are you asking for just the source files?
-----Original Message-----
From: Selvaratnam Uthaiyashankar [mailto:uthaiyashankar@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
<Mi...@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"
Re: Signature verification fails when signing the Body
Posted by Selvaratnam Uthaiyashankar <ut...@gmail.com>.
Hi,
Can you send the client code?
Regards,
Shankar
On Thu, Oct 15, 2009 at 4:38 PM, Doughty, Michael
<Mi...@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"
RE: Signature verification fails when signing the Body
Posted by "Doughty, Michael" <Mi...@bmc.com>.
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?