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:cohei...@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.courta...@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:cohei...@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.courta...@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.courta...@gemalto.com]
>> Sent: mercredi 11 avril 2012 17:59
>> To: cohei...@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:cohei...@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.courta...@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:cohei...@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.courta...@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: 'cohei...@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:dk...@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:cohei...@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.courta...@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:gma...@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
>>>> dk...@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
