cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From COURTAULT Francois <Francois.COURTA...@gemalto.com>
Subject RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Date Mon, 16 Apr 2012 15:35:34 GMT
Hello,

I have modified the policy at the server side in order to add a signed part (body) in the
response. If I dump the exchanges, the good news is that now I got no error from the server
but I got one at the client side: seems that the signature coming from the server was invalid
:-(

My code looks like:
                        Map<String, Object> ctx = ((BindingProvider) port).getRequestContext();
                        ctx.put("ws-security.username", "myClientKeystoreAlias");
                        ctx.put("ws-security.callback-handler", ClientX509CB.class.getName());
                        ctx.put("ws-security.signature.properties", "clientKeystore.properties");

where clientKeystore.properties contains:
        org.apache.ws.security.crypto.merlin.keystore.file=myClientKeystore.jks
        org.apache.ws.security.crypto.merlin.keystore.password=myClientKeystorePassword
        org.apache.ws.security.crypto.merlin.keystore.type=jks
        org.apache.ws.security.crypto.merlin.keystore.alias= myClientKeystoreAlias

So the clientKeystore is used for signing the SOAP request sent to the server but how can
the client verify the server signature ? What can I do ? What information is missing ?

Best Regards.

-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: vendredi 13 avril 2012 15:01
To: COURTAULT Francois
Cc: users@cxf.apache.org
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?

>    - *if* message level signature is used in the request: how do you know that message
level signature is required ?

By the use of a SignedParts or SignedElements policy.

> More generally, in the ws-securitypolicy-1.3-spec-os.pdf document there no real explanation
about the meaning of OnlySignEntireHeadersAndBody. So my own interpretation, for this one,
is that:
>         - a signature is required for each header blocks and for the body: no need to
say more.

That's not my interpretation of the spec. As I said previously, my reading is that a signature
can't be on a Body or Header child element if it exists. I agree that the spec isn't exactly
clear though. What's the problem with just including a SignedParts policy?

Colm.

On Fri, Apr 13, 2012 at 1:55 PM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
> Hello,
>
> Thanks for your answer.
> But I still have one question:
>    - *if* message level signature is used in the request: how do you know that message
level signature is required ? I was expecting that this is the purpose of the policy you attach
to a webservice endpoint and, in my case, OnlySignEntireHeadersAndBody policy means that signature
is required at message level.
>
> More generally, in the ws-securitypolicy-1.3-spec-os.pdf document there no real explanation
about the meaning of OnlySignEntireHeadersAndBody. So my own interpretation, for this one,
is that:
>         - a signature is required for each header blocks and for the body: no need to
say more.
>
> So, just for me to know: where did you find such information with more details regarding
OnlySignEntireHeadersAndBody ?
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: vendredi 13 avril 2012 12:02
> To: COURTAULT Francois
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Hi Francois,
>
> My reading of the spec is that a "OnlySignEntireHeadersAndBody" policy means that *if*
message level signature is used in the request, then it must not be a child element of the
SOAP Body, or a child element of a particular header, excepting the security header. It does
not mandate that signature must be performed, only that if signature is performed it must
conform to that policy. Therefore, a SignedParts or SignedElements policy is needed to specify
what must actually be signed.
>
> Colm.
>
>
> On Thu, Apr 12, 2012 at 11:32 AM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>> Hello,
>>
>> I have looked at the security policy spec (1.3) and it seems that SignedParts is
OPTIONAL: right ?
>> However this spec is not clear at all regarding the relationship
>> between the <sp:OnlySignEntireHeadersAndBody/> directive and the <sp:SignedParts/>
directive :-( Does the presence of the  <sp:OnlySignEntireHeadersAndBody/> directive
requires the <sp:SignedParts/> directive ?
>>
>> Any spec or document which can provide more clear explanation about the relationship
between these 2 above directives ?
>> So let's suppose that the <sp:OnlySignEntireHeadersAndBody/> could be used
alone, in such case does it mean that all the security headers and the body have to be signed
?
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
>> Sent: mercredi 11 avril 2012 17:59
>> To: coheigea@apache.org
>> Cc: users@cxf.apache.org
>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>> Importance: High
>>
>> Hello,
>>
>> Regarding your last question: Is there such a policy in your WSDL?
>> I have looked at the policy used (attached) and I only see <sp:OnlySignEntireHeadersAndBody/>
with no SignedParts.
>> So my question is: with the policy used(attached), is it required or not to sign
the body ?
>>
>> A corollary question is, with only the <sp:OnlySignEntireHeadersAndBody/> directive
in the policy, the webservice endpoint has to accept only SOAP request with at least a body
signature ?
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: mercredi 11 avril 2012 17:21
>> To: COURTAULT Francois
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> Hi Francois,
>>
>>>        - first, for them, in the <dsig:KeyInfo> section, they refer
>>> the wsse11 namespace which is used in
>>> wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3".
Is this TokenType mandatory ?
>>
>> Not according to my reading of the Basic Security Profile 1.1:
>>
>> http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html#x509tokent
>> y
>> pes
>>
>> They give the example:
>>
>> CORRECT:
>>
>>          <wsse:SecurityTokenReference>
>>          <wsse:KeyIdentifier
>> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>>          ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"
>>>
>>          MIGfMa0GCSq
>>          </wsse:KeyIdentifier>
>>          </wsse:SecurityTokenReference>
>>
>>>  - second, in the <ds:SignedInfo> section, the body signature seems missing
in the CXF SOAP request. Is it normal ?
>>
>> CXF will only sign the SOAP Body if there is a SignedParts policy that specifies
the SOAP Body. Is there such a policy in your WSDL?
>>
>> Colm.
>>
>>
>> On Wed, Apr 11, 2012 at 3:56 PM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>>> Hello again,
>>>
>>> I have forwarded your answer to the Oracle support. They replied me 2 things:
>>>        - first, for them, in the <dsig:KeyInfo> section, they refer the
wsse11 namespace which is used in wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3".
Is this TokenType mandatory ?
>>>
>>>        - second, in the <ds:SignedInfo> section, the body signature seems
missing in the CXF SOAP request. Is it normal ?
>>>             * In Weblogic request:
>>>                                <dsig:SignedInfo>
>>>                                        <dsig:CanonicalizationMethod
>>>
>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
>>>                                        <dsig:SignatureMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>>>                                        <dsig:Reference
>>> URI="#Timestamp_WF911A291H4C9EVH">
>>>                                                <dsig:Transforms>
>>>
>>> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
>>> />
>>>                                                </dsig:Transforms>
>>>                                                <dsig:DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>>>
>>> <dsig:DigestValue>FQdxW5uhQYvIlEjZ5eF6FwD0WWM=</dsig:DigestValue>
>>>                                        </dsig:Reference>
>>>                                        <dsig:Reference
>>> URI="#Body_6e1VPrhuvqnQBAe6">
>>>                                                <dsig:Transforms>
>>>
>>> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
>>> />
>>>                                                </dsig:Transforms>
>>>                                                <dsig:DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>>>
>>> <dsig:DigestValue>hqQ8dypeB6mi9otTZftZ9wdaIpQ=</dsig:DigestValue>
>>>                                        </dsig:Reference>
>>>                                        <dsig:Reference
>>> URI="#bst_156mJ1UUoTA9ZP7b">
>>>                                                <dsig:Transforms>
>>>
>>> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
>>> />
>>>                                                </dsig:Transforms>
>>>                                                <dsig:DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>>>
>>> <dsig:DigestValue>dmD/DqmQIf+LrHjcOgxLKhpCvZE=</dsig:DigestValue>
>>>                                        </dsig:Reference>
>>>                                </dsig:SignedInfo>
>>>
>>>             * In CXF request:
>>>                                <ds:SignedInfo>
>>>                                        <ds:CanonicalizationMethod
>>>
>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>>>                                                <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
>>>
>>> PrefixList="soap"></ec:InclusiveNamespaces>
>>>                                        </ds:CanonicalizationMethod>
>>>                                        <ds:SignatureMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:Signatur
>>> e
>>> M
>>> ethod>
>>>                                        <ds:Reference URI="#TS-1">
>>>                                                <ds:Transforms>
>>>                                                        <ds:Transform
>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>>>
>>> <ec:InclusiveNamespaces
>>>
>>> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse
>>> soap"></ec:InclusiveNamespaces>
>>>
>>> </ds:Transform>
>>>                                                </ds:Transforms>
>>>                                                <ds:DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod
>>> >
>>>
>>> <ds:DigestValue>qqnMVp6ogLp4FbJuMaenBdYlm3E=</ds:DigestValue>
>>>                                        </ds:Reference>
>>>                                        <ds:Reference
>>> URI="#X509-A8BAAB773C57F7C94113313097001254">
>>>                                                <ds:Transforms>
>>>                                                        <ds:Transform
>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>>>
>>> <ec:InclusiveNamespaces
>>>
>>> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
>>> PrefixList="soap"></ec:InclusiveNamespaces>
>>>
>>> </ds:Transform>
>>>                                                </ds:Transforms>
>>>                                                <ds:DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod
>>> >
>>>
>>> <ds:DigestValue>YZ0E9NbYropID0uM5ZQInOgSmYA=</ds:DigestValue>
>>>                                        </ds:Reference>
>>>                                </ds:SignedInfo>
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: mardi 10 avril 2012 17:18
>>> To: COURTAULT Francois
>>> Cc: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>>> So according to them, the following namespaces are missing in the CXF request:
>>>>          -  wsu
>>>>          -  wsse
>>>
>>> This is incorrect as both of these namespaces are defined in the security header
element.
>>>
>>> Colm.
>>>
>>> On Tue, Apr 10, 2012 at 3:38 PM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>>>> Hello,
>>>>
>>>> Just to inform you I have also entered an issue in MOS (My Oracle Support).
>>>>
>>>> The answer they gave me was that,
>>>> In the Weblogic client request I  had:
>>>>
>>>>                                <dsig:KeyInfo>
>>>>                                        <wsse:SecurityTokenReference
>>>>                                                xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>>>>                                                xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>>>>                                                xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>>>>                                                wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
>>>>
>>>> wsu:Id="str_4RaFdeoK8oynP98t">
>>>>                                                <wsse:KeyIdentifier
>>>>                                                        EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>>>>
>>>> ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-se
>>>> c
>>>> u
>>>> r
>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdent
>>>> i
>>>> f
>>>> i
>>>> er>
>>>>
>>>> </wsse:SecurityTokenReference>
>>>>                                </dsig:KeyInfo>
>>>>
>>>> Whereas, in the CXF client (CXF 2.5.3 SNAPSHOT), I had:
>>>>
>>>>                                <ds:KeyInfo
>>>> Id="KI-A8BAAB773C57F7C94113313097001252">
>>>>                                        <wsse:SecurityTokenReference
>>>> wsu:Id="STR-A8BAAB773C57F7C94113313097001253">
>>>>                                                <wsse:KeyIdentifier
>>>>                                                        EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>>>>
>>>> ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-se
>>>> c
>>>> u
>>>> r
>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdent
>>>> i
>>>> f
>>>> i
>>>> er>
>>>>
>>>> </wsse:SecurityTokenReference>
>>>>                                </ds:KeyInfo>
>>>>
>>>> So according to them, the following namespaces are missing in the CXF request:
>>>>          -  wsu
>>>>          -  wsse
>>>>
>>>> Do you agree ? If yes can we have a fix for that please ?
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: COURTAULT Francois
>>>> Sent: vendredi 9 mars 2012 17:36
>>>> To: 'coheigea@apache.org'
>>>> Cc: users@cxf.apache.org
>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>
>>>> Hello,
>>>>
>>>> I have picked up the 2.5.3-20120309.061736-28 snapshot.
>>>> In the SOAP request I saw now, in the SOAP request, the <wsse:KeyIdentifier>
section in the <dsig:KeyInfo> <wsse:SecurityTokenReference> section :-) (thanks
for this fix) but I still have a SOAP fault in the response coming from Weblogic :-(.
>>>>
>>>> Do you have an idea as I haven't so much information (log) on the Weblogic
side ?
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Daniel Kulp [mailto:dkulp@apache.org]
>>>> Sent: mercredi 7 mars 2012 19:38
>>>> To: users@cxf.apache.org
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>
>>>> On Tuesday, March 06, 2012 06:52:41 PM COURTAULT Francois wrote:
>>>>> Hello,
>>>>>
>>>>> Thanks for the feedback :-)
>>>>> According to the issue, it should be fixed in the 2.5.3 release: right
?
>>>>> When this version will be released ?
>>>>
>>>> Likely in a couple weeks.   We did a release on Jan 25th and we
>>>> normally shoot for about every 8 weeks or so.
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: mardi 6 mars 2012 18:36
>>>>> To: users@cxf.apache.org
>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>>
>>>>> It's an issue in CXF:
>>>>>
>>>>> https://issues.apache.org/jira/browse/CXF-4166
>>>>>
>>>>> I'll merge a fix shortly.
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Tue, Mar 6, 2012 at 3:13 PM, COURTAULT Francois
>>>> <Francois.COURTAULT@gemalto.com> wrote:
>>>>> > Hello Glen,
>>>>> >
>>>>> > The two issues (WSIT-1490 and WSIT-1590) you mention seem not
>>>>> > related to the issue I have got :-( I am not using STS (WS-Trust)
at all:
>>>>> >        -  WSIT-1490: no SAML used in the KeyIdentifier with a
>>>>> > #uuid in the SOAP request. -  WSIT-1590: no encoded email in the
SOAP request.
>>>>> >
>>>>> > Best Regards.
>>>>> >
>>>>> > -----Original Message-----
>>>>> > From: Glen Mazza [mailto:gmazza@talend.com]
>>>>> > Sent: mardi 6 mars 2012 15:20
>>>>> > To: users@cxf.apache.org
>>>>> > Subject: Re: Aware of compatibility issue between CXF and
>>>>> > Metro/Weblogic ?
>>>>> >
>>>>> > There's a couple of problems that seem to be on Metro's side
>>>>> > (http://java.net/jira/browse/WSIT-1490,
>>>>> > http://java.net/jira/browse/WSIT-1590) affecting
>>>>> > interoperability between the two stacks.  It would be great if
>>>>> > these were fixed, as both Metro and CXF are better off the more
>>>>> > interoperable they are with each other.  Feel free to vote for
>>>>> > these two issues.  :)
>>>>> >
>>>>> > Glen
>>>>> >
>>>>> > On 03/06/2012 07:03 AM, COURTAULT Francois wrote:
>>>>> >> Hello,
>>>>> >>
>>>>> >> I have tried to write a CXF client which talks to a WSS
>>>>> >> protected
>>>>> >> (X509Token)  webservice hosted in Weblogic (Metro based) but
>>>>> >> unfortunately I got a Soap fault error.
>>>>> >>
>>>>> >> If I compare a soap request which works and the one generated
>>>>> >> by CXF, the only difference I have seen is that in
>>>>> >> the<dsig:KeyInfo> <wsse:SecurityTokenReference>
 section, I
>>>>> >> have a<wsse:KeyIdentifier>  section in the one which succeeded
>>>>> >> whereas I haven't this section in the CXF one.
>>>>> >>
>>>>> >> Any advice ? Any idea ?
>>>>> >>
>>>>> >> Best Regards.
>>>>> >
>>>>> > --
>>>>> > Glen Mazza
>>>>> > Talend Community Coders - coders.talend.com
>>>>> > blog: www.jroller.com/gmazza
>>>>>
>>>>> --
>>>>> Colm O hEigeartaigh
>>>>>
>>>>> Talend Community Coder
>>>>> http://coders.talend.com
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>>>> http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com



--
Colm O hEigeartaigh

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

Mime
View raw message