Hi Will,

Actually I believe that the CXF client is producing the correct output. The
first (primary) signature is encrypted, and the supporting (endorsing)
signature is not encrypted. This meets the expectation of the
"EncryptSignature" policy which requires that only the primary signature be
encrypted.

The first thing I would check is to remove "EncryptSignature" from the
service to see if this is the error, or whether there is another problem.

Colm.

On Fri, Feb 20, 2015 at 4:32 PM, Will Warren <[email protected]>
wrote:

> Thanks Colm. See here: http://pastebin.com/fPAGFXV4 <
> http://pastebin.com/fPAGFXV4> hopefully that helps
>
> —
> Will
>
> > On Feb 20, 2015, at 11:23, Colm O hEigeartaigh <[email protected]>
> wrote:
> >
> > It looks like CXF is not honouring the EncryptSignature policy here.
> Could
> > you paste the actual security policy in question + I can take a look?
> >
> > Colm.
> >
> > On Fri, Feb 20, 2015 at 3:53 PM, Will Warren <[email protected]
> <mailto:[email protected]>>
> > wrote:
> >
> >> Hi there
> >>
> >> I’m having a hard time calling this service (let’s call it MyService)
> that
> >> is provided by a 3rd party. I’m using CXF 3.0.4. The service is a .NET
> WCF
> >> service that is secured by a separate STS. I’m able to authenticate with
> >> the STS and get the SAML token. I’m including the SAML token in my
> request
> >> to MyService but it is rejecting the request with the classic
> >> “javax.xml.ws.soap.SOAPFaultException: An error occurred when verifying
> >> security for the message.” message. The original XML of the response is:
> >>
> >> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"; xmlns:a="
> >> http://www.w3.org/2005/08/addressing";>
> >>  <s:Header>
> >>    <a:Action s:mustUnderstand="1">
> >> http://www.w3.org/2005/08/addressing/soap/fault</a:Action>
> >>
> >> <a:RelatesTo>urn:uuid:3a857e83-c9c1-4893-b439-86f3179b46d4</a:RelatesTo>
> >>  </s:Header>
> >>  <s:Body>
> >>    <s:Fault>
> >>      <s:Code>
> >>        <s:Value>s:Sender</s:Value>
> >>        <s:Subcode>
> >>          <s:Value xmlns:a="
> >>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >> ">a:InvalidSecurity</s:Value>
> >>        </s:Subcode>
> >>      </s:Code>
> >>      <s:Reason>
> >>        <s:Text xml:lang="en-US">An error occurred when verifying
> security
> >> for the message.</s:Text>
> >>      </s:Reason>
> >>    </s:Fault>
> >>  </s:Body>
> >> </s:Envelope>
> >>
> >> So my request must be wrongly formed in some way.
> >>
> >> The service provider sent me an sample XML request which is produced by
> a
> >> .NET application they have that calls the MyService. We compared the 2
> and
> >> found that there were some discrepancies in my request. I’m missing a
> whole
> >> EncryptedData section. The service provider believes that it’s to do
> with
> >> the MessageProtectionOrder on the server being
> >> SignBeforeEncryptAndEncryptSignature and my client is not honouring
> that.
> >> If this is the case, how do I convince my client of that? I don’t see
> any
> >> method calls in the API that would relate to that.
> >>
> >> Here’s the sample from the .NET application:
> http://pastebin.com/PJrgAdY6
> >> <http://pastebin.com/PJrgAdY6 <http://pastebin.com/PJrgAdY6>> and
> here’s the sample from my CXF client
> >> application: http://pastebin.com/rYiLdK5m <http://pastebin.com/rYiLdK5m>
> <http://pastebin.com/rYiLdK5m <http://pastebin.com/rYiLdK5m>>
> >>
> >> I snipped out the SAML token to save space in both, and also snipped all
> >> the CipherValue sections for the same reason.
> >>
> >> Thanks!
> >>
> >> —
> >> Will
> >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com <http://coders.talend.com/>
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Reply via email to