Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>
Received-SPF: pass (athena.apache.org: domain of uthaiyashankar@gmail.com
 designates 209.85.216.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=oDvwTaUECcr3+7TFHHbsA2pYJEoGMdqBQ+c2v0pOYal6J0pVdeJM96DWtynxgDF9D3
         WkiwIi0JyAmRVab+FqFwu45QXx1lAtyK9DjSR2UMFxyn1iYkCmwdUbkCV38oIOLHk4hY
         oVIfbRlt+qOsVIGhPz9ZGFUsz60UtF8cqUuiQ=
MIME-Version: 1.0
In-Reply-To: 
 <5E8C8BE519C8C9458BA2382E368E56C7136BD74183@PHXCCRPRD01.adprod.bmc.com>
References: 
 <5E8C8BE519C8C9458BA2382E368E56C7136B70F8E5@PHXCCRPRD01.adprod.bmc.com>
	 <5E8C8BE519C8C9458BA2382E368E56C7136BD74183@PHXCCRPRD01.adprod.bmc.com>
Date: Fri, 16 Oct 2009 08:55:27 +0530
Message-ID: <84cacd920910152025p224c83eaqe0e6cf40c2dbe822@mail.gmail.com>
Subject: Re: Signature verification fails when signing the Body
From: Selvaratnam Uthaiyashankar <uthaiyashankar@gmail.com>
To: Apache AXIS C User List <axis-c-user@ws.apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.=A0 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=3Daxis-c-user&m=3D122333172329075&w=3D2
>
>
>
> The problem is that it ended without a reply showing a resolution, so it
> didn=92t really help me understand what is going on or how to possibly fi=
x the
> issue.
>
>
>
> I wanted to validate that this same condition occurred when I used differ=
ent
> client and server-side asymmetric keys, so I=92ve 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)=A0 Signing both the Body and UsernameToken
>
> (2)=A0 Signing only the Body
>
> (3)=A0 Signing only the UsernameToken
>
>
>
> I ran the test using both Rampart/C with Axis/C and WSS4J in a testing
> tool.=A0 The WSS4J signatures all work properly with the keys and certs I=
=92ve
> included after they were stored away in JKS files.=A0 Rampart/C messages =
fail
> signature checking however whenever the Body is signed, so scenarios 1 an=
d 2
> fail, while scenario 3 works fine despite a signature being applied to
> UsernameToken.
>
>
>
> I=92ve 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.=A0 The keys are non-produc=
tion
> testing keys I created specifically for this.=A0 The directory structure =
is as
> follows:
>
>
>
> PEM files:
>
> pem-files\server.cer =96 Server=92s public key in PEM format
>
> pem-files\server.pem =96 Server=92s private key in PEM format
>
> pem-files\client.cer =96 Client=92s public key in PEM format
>
> pem-files\client.pem =96 Client=92s private key in PEM format
>
>
>
> JKS files:
>
> jks-files\server.jks =96 Server=92s JKS keystore file.=A0 The keystore pa=
ssword is
> =93testing=94, the alias is =93server=94, and the key password is =93test=
ing=94.
>
> jks-files\server.jks =96 Client=92s JKS keystore file.=A0 The keystore pa=
ssword is
> =93testing=94, the alias is =93client=94, and the key password is =93test=
ing=94.
>
>
>
> 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:UsernameTok=
en
>
>
>
> Rampart/C Client Requests:
>
> rampartc-requests\SIGN-BODY-AND-UT.request.xml - Request with both SOAP:B=
ody
> 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:Bo=
dy
> 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=92d appreciate it.=A0 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.=A0 These We=
b
> 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=92t suppor=
t XML
> encryption, we decided on using Axis2/C and Rampart/C.
>
>
>
> The problem is that something isn=92t quite working right on the signing =
of
> the content.=A0 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: =93An error occured while processing the message security header=
:
> Signature verification failed=94.
>
>
>
> This has perplexed me for a while, because the other tools I=92ve been us=
ing
> seem to work properly. =A0I=92ve written clients in Systinet Server for J=
ava
> using their WS-Security implementation, Axis2/Rampart for Java, and
> =A0Axis/WSS4J implementation, all of which work properly.
>
>
>
> I took a look at the fault message that was returned to the Axis2/C clien=
t,
> as it included a Java exception stack, and I see that the Web services ar=
e
> using an implementation of security by Amberpoint along with Entrust
> security libraries.=A0 So I decided to make sure this was not an
> implementation issue with those tools.=A0 I created a fake service from o=
ne of
> the services=92 WSDL files using a testing tool I have which uses WSS4J a=
s its
> WS-Security implementation.=A0 The fake service returns a similar error:
> =93org.apache.wss4j11.security.WSSecurityException: The signature verific=
ation
> failed.=94
>
>
>
> Since I can=92t 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=92s policy.xml file.=A0 It turns ou=
t that
> everything works fine except when I try to sign the body.=A0 It is when I=
 sign
> the body that the signature fails.=A0 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=92t signed when it is required to be.
>
>
>
> Is this a known issue?=A0 I am using the 1.3.0 release.=A0 Is there any w=
ay to
> work around it that won=92t require me to change security policies on the
> services I am trying to consume?


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