You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by COURTAULT Francois <Fr...@gemalto.com> on 2012/04/10 16:38:20 UTC
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
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-security-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifier>
</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-security-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifier>
</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
<Fr...@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
Fwd: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
(Accidentally omitted the list).
Colm.
---------- Forwarded message ----------
From: Colm O hEigeartaigh <co...@apache.org>
Date: Wed, Apr 11, 2012 at 4:20 PM
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
To: COURTAULT Francois <Fr...@gemalto.com>
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#x509tokentypes
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
<Fr...@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:SignatureMethod>
> <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 <Fr...@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-secur
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifi
>> 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-secur
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifi
>> 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
>> <Fr...@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
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Any feedback ?
Best Regards.
-----Original Message-----
From: COURTAULT Francois
Sent: jeudi 12 avril 2012 12:32
To: coheigea@apache.org
Cc: users@cxf.apache.org
Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
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#x509tokentypes
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 <Fr...@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:SignatureM
> 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 <Fr...@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-secu
>> r
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentif
>> 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-secu
>> r
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentif
>> 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
>> <Fr...@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
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello,
Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-(
I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
java.util.logging.ConsoleHandler.level = FINEST
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
org.apache.cxf.level = FINEST
Again no cxf log ???
Really I need some help in order to solve my issue.
Best Regards.
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: mardi 17 avril 2012 11:26
To: users@cxf.apache.org
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Try adding in the following dependency:
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
Failing that take a look at any of the STS systests in CXF to see how logging works there.
Colm.
On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
> Hello,
>
> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>
> Where in the cxf-logging.properties I have:
> .level= FINEST
> java.util.logging.ConsoleHandler.level = FINEST
>
> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: lundi 16 avril 2012 18:24
> To: COURTAULT Francois
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>
> Colm.
>
> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> 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.j
>> k
>> s
>>
>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeysto
>> r
>> ePassword
>> 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 <Fr...@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 <Fr...@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#x509toke
>>>> n
>>>> t
>>>> 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 <Fr...@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:Signat
>>>>> u
>>>>> r
>>>>> 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:DigestMeth
>>>>> o
>>>>> d
>>>>> >
>>>>>
>>>>> <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:DigestMeth
>>>>> o
>>>>> d
>>>>> >
>>>>>
>>>>> <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 <Fr...@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-
>>>>>> s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIde
>>>>>> n
>>>>>> t
>>>>>> 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-
>>>>>> s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIde
>>>>>> n
>>>>>> t
>>>>>> 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
>>>>>> <Fr...@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
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello,
I have made some tests against 2.5.4-SNAPSHOT and 2.6.1-SNAPSHOT and it works now :-)
Thank you very much.
Best Regards.
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: vendredi 20 avril 2012 15:17
To: Gary Gregory
Cc: <us...@cxf.apache.org>; COURTAULT Francois
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Here it is then:
https://issues.apache.org/jira/browse/CXF-4254
Colm.
On Fri, Apr 20, 2012 at 1:50 PM, Gary Gregory <GG...@rocketsoftware.com> wrote:
> On Apr 20, 2012, at 8:39, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>
>>> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
>>
>> Right. However, if you are signing something it generally *must* be
>> included in the request, unless in this case where you are using a
>> SecurityTokenReference transform.
>>
>>> - Could you please give me the JIRA issue number linked to this problem ?
>>> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
>>> - Should it be fixed in the next release ? which one ?
>>
>> I didn't create a JIRA, but the fix has been committed and so it
>> should appear in the next SNAPSHOTS for 2.4.8-SNAPSHOT,
>> 2.5.4-SNAPSHOT or 2.6.1-SNAPSHOT when they get built.
>
> A Jira would be most helpful to note that a fix was made in this area.
>
> Gary
>>
>> Colm.
>>
>> On Fri, Apr 20, 2012 at 1:10 PM, COURTAULT Francois
>> <Fr...@gemalto.com> wrote:
>>> Hello,
>>>
>>> "Please take care to reply to the mailing list instead of directly to me."
>>> Understood !
>>>
>>> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
>>> <sp:RecipientToken>
>>> <wsp:Policy>
>>> <sp:X509Token
>>>
>>> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> 200702/IncludeToken/Never">
>>> <wsp:Policy>
>>> <sp:RequireThumbprintReference/>
>>> <sp:WssX509V3Token11/>
>>> </wsp:Policy>
>>> </sp:X509Token>
>>> </wsp:Policy>
>>> </sp:RecipientToken>
>>>
>>> Am I wrong ?
>>>
>>> Anyway:
>>> - Could you please give me the JIRA issue number linked to this problem ?
>>> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
>>> - Should it be fixed in the next release ? which one ?
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: vendredi 20 avril 2012 12:27
>>> To: COURTAULT Francois
>>> Cc: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Hi Francois,
>>>
>>> Please take care to reply to the mailing list instead of directly to me.
>>>
>>> There is a bug in CXF when validating the OnlySignEntireHeadersAndBody property. In this particular response, the SecurityTokenReference Transform is used to dereference a SecurityTokenReference for signature. The result is a BinarySecurityToken that is not included in the message request. CXF always assumes that the signed Element is in the message request, which is not necessarily true.
>>>
>>> I'll merge a fix for this shortly. In the meantime, you can get around the problem by disabling OnlySignEntireHeadersAndBody, or else stop the server signing the signature key.
>>>
>>> Colm.
>>>
>>> On Fri, Apr 20, 2012 at 10:56 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> Hello,
>>>>
>>>> Attached is the SOAP request and also the Response which causes the error.
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: vendredi 20 avril 2012 10:29
>>>> To: COURTAULT Francois
>>>> Cc: users@cxf.apache.org
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> Could you attach the SOAP Message that's causing that error?
>>>>
>>>> Colm.
>>>>
>>>> On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>> Hello,
>>>>>
>>>>> My tests:
>>>>> - with no truststore properties in the
>>>>> clientKeystore.properties, I got the error: The signature or
>>>>> decryption was invalid
>>>>> - with truststore properties in the clientKeystore.properties,
>>>>> I got the error: Fault string, and possibly fault code, not set
>>>>> Caused by: java.lang.NullPointerException
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingP
>>>>> oli
>>>>> c
>>>>> yValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPo
>>>>> lic
>>>>> y
>>>>> Validator.java:117)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingP
>>>>> oli
>>>>> c
>>>>> yValidator.checkProperties(AbstractBindingPolicyValidator.java:198
>>>>> )
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindin
>>>>> gPo
>>>>> l
>>>>> icyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:
>>>>> 76)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.che
>>>>> ckB
>>>>> i
>>>>> ndingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doR
>>>>> esu
>>>>> l
>>>>> ts(PolicyBasedWSS4JInInterceptor.java:556)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(
>>>>> WSS
>>>>> 4
>>>>> JInInterceptor.java:275)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(
>>>>> WSS
>>>>> 4
>>>>> JInInterceptor.java:86)
>>>>> at
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterc
>>>>> ept
>>>>> o
>>>>> rChain.java:263)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.hand
>>>>> leR
>>>>> e
>>>>> sponseInternal(HTTPConduit.java:1635)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.hand
>>>>> leR
>>>>> e
>>>>> sponse(HTTPConduit.java:1502)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.clos
>>>>> e(H
>>>>> T
>>>>> TPConduit.java:1410)
>>>>> at
>>>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.jav
>>>>> a:5
>>>>> 6
>>>>> )
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:6
>>>>> 50)
>>>>> at
>>>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderE
>>>>> ndi
>>>>> n
>>>>> gInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>>> at
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterc
>>>>> ept
>>>>> o
>>>>> rChain.java:263)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
>>>>> at
>>>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88
>>>>> )
>>>>> at
>>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java
>>>>> :13
>>>>> 4
>>>>> )
>>>>>
>>>>> Any idea ?
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: jeudi 19 avril 2012 15:19
>>>>> To: COURTAULT Francois
>>>>> Cc: users@cxf.apache.org
>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>
>>>>> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>>>>>
>>>>> org.apache.ws.security.crypto.merlin.truststore.file=
>>>>> org.apache.ws.security.crypto.merlin.truststore.password=
>>>>>
>>>>> http://ws.apache.org/wss4j/config.html
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>> Hello again,
>>>>>>
>>>>>> Just one remark, before invoking a webservice method, I have those code lines:
>>>>>> Map<String, Object> ctx =
>>>>>> ((BindingProvider) port).getRequestContext();
>>>>>> ctx.put("ws-security.username",
>>>>>> "wssclientcertificate");
>>>>>> ctx.put("ws-security.callback-handler",
>>>>>> ClientX509CB.class.getName());
>>>>>>
>>>>>> ctx.put("ws-security.signature.properties",
>>>>>> "clientKeystore.properties");
>>>>>>
>>>>>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>>>>>> 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
>>>>>>
>>>>>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>>>>>
>>>>>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>>>>>
>>>>>>
>>>>>> Best Regards.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: COURTAULT Francois
>>>>>> Sent: mercredi 18 avril 2012 20:34
>>>>>> To: users@cxf.apache.org
>>>>>> Cc: 'coheigea@apache.org'
>>>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>>>>>
>>>>>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>>> java.util.logging.ConsoleHandler.formatter =
>>>>>> java.util.logging.SimpleFormatter
>>>>>>
>>>>>> org.apache.cxf.level = FINEST
>>>>>>
>>>>>> Again no cxf log ???
>>>>>>
>>>>>> Really I need some help in order to solve my issue.
>>>>>>
>>>>>> Best Regards.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>>> Sent: mardi 17 avril 2012 11:26
>>>>>> To: users@cxf.apache.org
>>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>>
>>>>>> Try adding in the following dependency:
>>>>>>
>>>>>> <groupId>org.slf4j</groupId>
>>>>>> <artifactId>slf4j-jdk14</artifactId>
>>>>>>
>>>>>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>>>>>
>>>>>> Colm.
>>>>>>
>>>>>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>>>>>
>>>>>>> Where in the cxf-logging.properties I have:
>>>>>>> .level= FINEST
>>>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>>>>
>>>>>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>>>>>
>>>>>>> Best Regards.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>>>> Sent: lundi 16 avril 2012 18:24
>>>>>>> To: COURTAULT Francois
>>>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>>>
>>>>>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>>>>>
>>>>>>> Colm.
>>>>>>>
>>>>>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>>>> 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.
>>>>>>>> j
>>>>>>>> k
>>>>>>>> s
>>>>>>>>
>>>>>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClient
>>>>>>>> Key
>>>>>>>> s
>>>>>>>> t
>>>>>>>> o
>>>>>>>> r
>>>>>>>> ePassword
>>>>>>>> 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 <Fr...@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 <Fr...@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#x5
>>>>>>>>>> 09t
>>>>>>>>>> o
>>>>>>>>>> k
>>>>>>>>>> e
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> 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 <Fr...@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:DigestV
>>>>>>>>>>> alu
>>>>>>>>>>> e
>>>>>>>>>>>>
>>>>>>>>>>> </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:DigestV
>>>>>>>>>>> alu
>>>>>>>>>>> e
>>>>>>>>>>>>
>>>>>>>>>>> </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:DigestV
>>>>>>>>>>> alu
>>>>>>>>>>> e
>>>>>>>>>>>>
>>>>>>>>>>> </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:
>>>>>>>>>>> Sig
>>>>>>>>>>> n
>>>>>>>>>>> a
>>>>>>>>>>> t
>>>>>>>>>>> u
>>>>>>>>>>> r
>>>>>>>>>>> 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:Dige
>>>>>>>>>>> stM
>>>>>>>>>>> e
>>>>>>>>>>> t
>>>>>>>>>>> h
>>>>>>>>>>> o
>>>>>>>>>>> d
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <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:Dige
>>>>>>>>>>> stM
>>>>>>>>>>> e
>>>>>>>>>>> t
>>>>>>>>>>> h
>>>>>>>>>>> o
>>>>>>>>>>> d
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <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 <Fr...@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-me
>>>>>>>>>>>> ssa
>>>>>>>>>>>> g
>>>>>>>>>>>> e
>>>>>>>>>>>> -
>>>>>>>>>>>> s
>>>>>>>>>>>> e
>>>>>>>>>>>> c
>>>>>>>>>>>> u
>>>>>>>>>>>> r
>>>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:
>>>>>>>>>>>> Key
>>>>>>>>>>>> I
>>>>>>>>>>>> d
>>>>>>>>>>>> e
>>>>>>>>>>>> n
>>>>>>>>>>>> t
>>>>>>>>>>>> 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-me
>>>>>>>>>>>> ssa
>>>>>>>>>>>> g
>>>>>>>>>>>> e
>>>>>>>>>>>> -
>>>>>>>>>>>> s
>>>>>>>>>>>> e
>>>>>>>>>>>> c
>>>>>>>>>>>> u
>>>>>>>>>>>> r
>>>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:
>>>>>>>>>>>> Key
>>>>>>>>>>>> I
>>>>>>>>>>>> d
>>>>>>>>>>>> e
>>>>>>>>>>>> n
>>>>>>>>>>>> t
>>>>>>>>>>>> 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
>>>>>>>>>>>> <Fr...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Here it is then:
https://issues.apache.org/jira/browse/CXF-4254
Colm.
On Fri, Apr 20, 2012 at 1:50 PM, Gary Gregory
<GG...@rocketsoftware.com> wrote:
> On Apr 20, 2012, at 8:39, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>
>>> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
>>
>> Right. However, if you are signing something it generally *must* be
>> included in the request, unless in this case where you are using a
>> SecurityTokenReference transform.
>>
>>> - Could you please give me the JIRA issue number linked to this problem ?
>>> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
>>> - Should it be fixed in the next release ? which one ?
>>
>> I didn't create a JIRA, but the fix has been committed and so it
>> should appear in the next SNAPSHOTS for 2.4.8-SNAPSHOT, 2.5.4-SNAPSHOT
>> or 2.6.1-SNAPSHOT when they get built.
>
> A Jira would be most helpful to note that a fix was made in this area.
>
> Gary
>>
>> Colm.
>>
>> On Fri, Apr 20, 2012 at 1:10 PM, COURTAULT Francois
>> <Fr...@gemalto.com> wrote:
>>> Hello,
>>>
>>> "Please take care to reply to the mailing list instead of directly to me."
>>> Understood !
>>>
>>> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
>>> <sp:RecipientToken>
>>> <wsp:Policy>
>>> <sp:X509Token
>>> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
>>> <wsp:Policy>
>>> <sp:RequireThumbprintReference/>
>>> <sp:WssX509V3Token11/>
>>> </wsp:Policy>
>>> </sp:X509Token>
>>> </wsp:Policy>
>>> </sp:RecipientToken>
>>>
>>> Am I wrong ?
>>>
>>> Anyway:
>>> - Could you please give me the JIRA issue number linked to this problem ?
>>> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
>>> - Should it be fixed in the next release ? which one ?
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: vendredi 20 avril 2012 12:27
>>> To: COURTAULT Francois
>>> Cc: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Hi Francois,
>>>
>>> Please take care to reply to the mailing list instead of directly to me.
>>>
>>> There is a bug in CXF when validating the OnlySignEntireHeadersAndBody property. In this particular response, the SecurityTokenReference Transform is used to dereference a SecurityTokenReference for signature. The result is a BinarySecurityToken that is not included in the message request. CXF always assumes that the signed Element is in the message request, which is not necessarily true.
>>>
>>> I'll merge a fix for this shortly. In the meantime, you can get around the problem by disabling OnlySignEntireHeadersAndBody, or else stop the server signing the signature key.
>>>
>>> Colm.
>>>
>>> On Fri, Apr 20, 2012 at 10:56 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> Hello,
>>>>
>>>> Attached is the SOAP request and also the Response which causes the error.
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: vendredi 20 avril 2012 10:29
>>>> To: COURTAULT Francois
>>>> Cc: users@cxf.apache.org
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> Could you attach the SOAP Message that's causing that error?
>>>>
>>>> Colm.
>>>>
>>>> On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>> Hello,
>>>>>
>>>>> My tests:
>>>>> - with no truststore properties in the clientKeystore.properties,
>>>>> I got the error: The signature or decryption was invalid
>>>>> - with truststore properties in the clientKeystore.properties, I
>>>>> got the error: Fault string, and possibly fault code, not set
>>>>> Caused by: java.lang.NullPointerException
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>>>>> c
>>>>> yValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPolic
>>>>> y
>>>>> Validator.java:117)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>>>>> c
>>>>> yValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPo
>>>>> l
>>>>> icyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkB
>>>>> i
>>>>> ndingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResu
>>>>> l
>>>>> ts(PolicyBasedWSS4JInInterceptor.java:556)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>>>>> 4
>>>>> JInInterceptor.java:275)
>>>>> at
>>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>>>>> 4
>>>>> JInInterceptor.java:86)
>>>>> at
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>>>>> o
>>>>> rChain.java:263)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>>>>> e
>>>>> sponseInternal(HTTPConduit.java:1635)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>>>>> e
>>>>> sponse(HTTPConduit.java:1502)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H
>>>>> T
>>>>> TPConduit.java:1410)
>>>>> at
>>>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:5
>>>>> 6
>>>>> )
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650)
>>>>> at
>>>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi
>>>>> n
>>>>> gInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>>> at
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>>>>> o
>>>>> rChain.java:263)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
>>>>> at
>>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
>>>>> at
>>>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
>>>>> at
>>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:13
>>>>> 4
>>>>> )
>>>>>
>>>>> Any idea ?
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: jeudi 19 avril 2012 15:19
>>>>> To: COURTAULT Francois
>>>>> Cc: users@cxf.apache.org
>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>
>>>>> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>>>>>
>>>>> org.apache.ws.security.crypto.merlin.truststore.file=
>>>>> org.apache.ws.security.crypto.merlin.truststore.password=
>>>>>
>>>>> http://ws.apache.org/wss4j/config.html
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>> Hello again,
>>>>>>
>>>>>> Just one remark, before invoking a webservice method, I have those code lines:
>>>>>> Map<String, Object> ctx = ((BindingProvider)
>>>>>> port).getRequestContext();
>>>>>> ctx.put("ws-security.username",
>>>>>> "wssclientcertificate");
>>>>>> ctx.put("ws-security.callback-handler",
>>>>>> ClientX509CB.class.getName());
>>>>>> ctx.put("ws-security.signature.properties",
>>>>>> "clientKeystore.properties");
>>>>>>
>>>>>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>>>>>> 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
>>>>>>
>>>>>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>>>>>
>>>>>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>>>>>
>>>>>>
>>>>>> Best Regards.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: COURTAULT Francois
>>>>>> Sent: mercredi 18 avril 2012 20:34
>>>>>> To: users@cxf.apache.org
>>>>>> Cc: 'coheigea@apache.org'
>>>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>>>>>
>>>>>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>>> java.util.logging.ConsoleHandler.formatter =
>>>>>> java.util.logging.SimpleFormatter
>>>>>>
>>>>>> org.apache.cxf.level = FINEST
>>>>>>
>>>>>> Again no cxf log ???
>>>>>>
>>>>>> Really I need some help in order to solve my issue.
>>>>>>
>>>>>> Best Regards.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>>> Sent: mardi 17 avril 2012 11:26
>>>>>> To: users@cxf.apache.org
>>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>>
>>>>>> Try adding in the following dependency:
>>>>>>
>>>>>> <groupId>org.slf4j</groupId>
>>>>>> <artifactId>slf4j-jdk14</artifactId>
>>>>>>
>>>>>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>>>>>
>>>>>> Colm.
>>>>>>
>>>>>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>>>>>
>>>>>>> Where in the cxf-logging.properties I have:
>>>>>>> .level= FINEST
>>>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>>>>
>>>>>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>>>>>
>>>>>>> Best Regards.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>>>> Sent: lundi 16 avril 2012 18:24
>>>>>>> To: COURTAULT Francois
>>>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>>>
>>>>>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>>>>>
>>>>>>> Colm.
>>>>>>>
>>>>>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>>>> 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.
>>>>>>>> j
>>>>>>>> k
>>>>>>>> s
>>>>>>>>
>>>>>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKey
>>>>>>>> s
>>>>>>>> t
>>>>>>>> o
>>>>>>>> r
>>>>>>>> ePassword
>>>>>>>> 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 <Fr...@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 <Fr...@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#x509t
>>>>>>>>>> o
>>>>>>>>>> k
>>>>>>>>>> e
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> 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 <Fr...@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:DigestValu
>>>>>>>>>>> e
>>>>>>>>>>>>
>>>>>>>>>>> </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:DigestValu
>>>>>>>>>>> e
>>>>>>>>>>>>
>>>>>>>>>>> </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:DigestValu
>>>>>>>>>>> e
>>>>>>>>>>>>
>>>>>>>>>>> </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:Sig
>>>>>>>>>>> n
>>>>>>>>>>> a
>>>>>>>>>>> t
>>>>>>>>>>> u
>>>>>>>>>>> r
>>>>>>>>>>> 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:DigestM
>>>>>>>>>>> e
>>>>>>>>>>> t
>>>>>>>>>>> h
>>>>>>>>>>> o
>>>>>>>>>>> d
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <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:DigestM
>>>>>>>>>>> e
>>>>>>>>>>> t
>>>>>>>>>>> h
>>>>>>>>>>> o
>>>>>>>>>>> d
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <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 <Fr...@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-messa
>>>>>>>>>>>> g
>>>>>>>>>>>> e
>>>>>>>>>>>> -
>>>>>>>>>>>> s
>>>>>>>>>>>> e
>>>>>>>>>>>> c
>>>>>>>>>>>> u
>>>>>>>>>>>> r
>>>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>>>>> I
>>>>>>>>>>>> d
>>>>>>>>>>>> e
>>>>>>>>>>>> n
>>>>>>>>>>>> t
>>>>>>>>>>>> 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-messa
>>>>>>>>>>>> g
>>>>>>>>>>>> e
>>>>>>>>>>>> -
>>>>>>>>>>>> s
>>>>>>>>>>>> e
>>>>>>>>>>>> c
>>>>>>>>>>>> u
>>>>>>>>>>>> r
>>>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>>>>> I
>>>>>>>>>>>> d
>>>>>>>>>>>> e
>>>>>>>>>>>> n
>>>>>>>>>>>> t
>>>>>>>>>>>> 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
>>>>>>>>>>>> <Fr...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>
>>>
>>>
>>> --
>>> 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
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Gary Gregory <GG...@rocketsoftware.com>.
On Apr 20, 2012, at 8:39, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
>
> Right. However, if you are signing something it generally *must* be
> included in the request, unless in this case where you are using a
> SecurityTokenReference transform.
>
>> - Could you please give me the JIRA issue number linked to this problem ?
>> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
>> - Should it be fixed in the next release ? which one ?
>
> I didn't create a JIRA, but the fix has been committed and so it
> should appear in the next SNAPSHOTS for 2.4.8-SNAPSHOT, 2.5.4-SNAPSHOT
> or 2.6.1-SNAPSHOT when they get built.
A Jira would be most helpful to note that a fix was made in this area.
Gary
>
> Colm.
>
> On Fri, Apr 20, 2012 at 1:10 PM, COURTAULT Francois
> <Fr...@gemalto.com> wrote:
>> Hello,
>>
>> "Please take care to reply to the mailing list instead of directly to me."
>> Understood !
>>
>> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
>> <sp:RecipientToken>
>> <wsp:Policy>
>> <sp:X509Token
>> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
>> <wsp:Policy>
>> <sp:RequireThumbprintReference/>
>> <sp:WssX509V3Token11/>
>> </wsp:Policy>
>> </sp:X509Token>
>> </wsp:Policy>
>> </sp:RecipientToken>
>>
>> Am I wrong ?
>>
>> Anyway:
>> - Could you please give me the JIRA issue number linked to this problem ?
>> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
>> - Should it be fixed in the next release ? which one ?
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: vendredi 20 avril 2012 12:27
>> To: COURTAULT Francois
>> Cc: users@cxf.apache.org
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> Hi Francois,
>>
>> Please take care to reply to the mailing list instead of directly to me.
>>
>> There is a bug in CXF when validating the OnlySignEntireHeadersAndBody property. In this particular response, the SecurityTokenReference Transform is used to dereference a SecurityTokenReference for signature. The result is a BinarySecurityToken that is not included in the message request. CXF always assumes that the signed Element is in the message request, which is not necessarily true.
>>
>> I'll merge a fix for this shortly. In the meantime, you can get around the problem by disabling OnlySignEntireHeadersAndBody, or else stop the server signing the signature key.
>>
>> Colm.
>>
>> On Fri, Apr 20, 2012 at 10:56 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> Hello,
>>>
>>> Attached is the SOAP request and also the Response which causes the error.
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: vendredi 20 avril 2012 10:29
>>> To: COURTAULT Francois
>>> Cc: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Could you attach the SOAP Message that's causing that error?
>>>
>>> Colm.
>>>
>>> On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> Hello,
>>>>
>>>> My tests:
>>>> - with no truststore properties in the clientKeystore.properties,
>>>> I got the error: The signature or decryption was invalid
>>>> - with truststore properties in the clientKeystore.properties, I
>>>> got the error: Fault string, and possibly fault code, not set
>>>> Caused by: java.lang.NullPointerException
>>>> at
>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>>>> c
>>>> yValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPolic
>>>> y
>>>> Validator.java:117)
>>>> at
>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>>>> c
>>>> yValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
>>>> at
>>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPo
>>>> l
>>>> icyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)
>>>> at
>>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkB
>>>> i
>>>> ndingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
>>>> at
>>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResu
>>>> l
>>>> ts(PolicyBasedWSS4JInInterceptor.java:556)
>>>> at
>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>>>> 4
>>>> JInInterceptor.java:275)
>>>> at
>>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>>>> 4
>>>> JInInterceptor.java:86)
>>>> at
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>>>> o
>>>> rChain.java:263)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
>>>> at
>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>>>> e
>>>> sponseInternal(HTTPConduit.java:1635)
>>>> at
>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>>>> e
>>>> sponse(HTTPConduit.java:1502)
>>>> at
>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H
>>>> T
>>>> TPConduit.java:1410)
>>>> at
>>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:5
>>>> 6
>>>> )
>>>> at
>>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650)
>>>> at
>>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi
>>>> n
>>>> gInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>> at
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>>>> o
>>>> rChain.java:263)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
>>>> at
>>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
>>>> at
>>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
>>>> at
>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:13
>>>> 4
>>>> )
>>>>
>>>> Any idea ?
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: jeudi 19 avril 2012 15:19
>>>> To: COURTAULT Francois
>>>> Cc: users@cxf.apache.org
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>>>>
>>>> org.apache.ws.security.crypto.merlin.truststore.file=
>>>> org.apache.ws.security.crypto.merlin.truststore.password=
>>>>
>>>> http://ws.apache.org/wss4j/config.html
>>>>
>>>> Colm.
>>>>
>>>> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>> Hello again,
>>>>>
>>>>> Just one remark, before invoking a webservice method, I have those code lines:
>>>>> Map<String, Object> ctx = ((BindingProvider)
>>>>> port).getRequestContext();
>>>>> ctx.put("ws-security.username",
>>>>> "wssclientcertificate");
>>>>> ctx.put("ws-security.callback-handler",
>>>>> ClientX509CB.class.getName());
>>>>> ctx.put("ws-security.signature.properties",
>>>>> "clientKeystore.properties");
>>>>>
>>>>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>>>>> 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
>>>>>
>>>>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>>>>
>>>>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>>>>
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: COURTAULT Francois
>>>>> Sent: mercredi 18 avril 2012 20:34
>>>>> To: users@cxf.apache.org
>>>>> Cc: 'coheigea@apache.org'
>>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>
>>>>> Hello,
>>>>>
>>>>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>>>>
>>>>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>> java.util.logging.ConsoleHandler.formatter =
>>>>> java.util.logging.SimpleFormatter
>>>>>
>>>>> org.apache.cxf.level = FINEST
>>>>>
>>>>> Again no cxf log ???
>>>>>
>>>>> Really I need some help in order to solve my issue.
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: mardi 17 avril 2012 11:26
>>>>> To: users@cxf.apache.org
>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>
>>>>> Try adding in the following dependency:
>>>>>
>>>>> <groupId>org.slf4j</groupId>
>>>>> <artifactId>slf4j-jdk14</artifactId>
>>>>>
>>>>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>>>>
>>>>>> Where in the cxf-logging.properties I have:
>>>>>> .level= FINEST
>>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>>>
>>>>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>>>>
>>>>>> Best Regards.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>>> Sent: lundi 16 avril 2012 18:24
>>>>>> To: COURTAULT Francois
>>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>>
>>>>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>>>>
>>>>>> Colm.
>>>>>>
>>>>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>>> 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.
>>>>>>> j
>>>>>>> k
>>>>>>> s
>>>>>>>
>>>>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKey
>>>>>>> s
>>>>>>> t
>>>>>>> o
>>>>>>> r
>>>>>>> ePassword
>>>>>>> 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 <Fr...@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 <Fr...@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#x509t
>>>>>>>>> o
>>>>>>>>> k
>>>>>>>>> e
>>>>>>>>> n
>>>>>>>>> t
>>>>>>>>> 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 <Fr...@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:DigestValu
>>>>>>>>>> e
>>>>>>>>>>>
>>>>>>>>>> </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:DigestValu
>>>>>>>>>> e
>>>>>>>>>>>
>>>>>>>>>> </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:DigestValu
>>>>>>>>>> e
>>>>>>>>>>>
>>>>>>>>>> </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:Sig
>>>>>>>>>> n
>>>>>>>>>> a
>>>>>>>>>> t
>>>>>>>>>> u
>>>>>>>>>> r
>>>>>>>>>> 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:DigestM
>>>>>>>>>> e
>>>>>>>>>> t
>>>>>>>>>> h
>>>>>>>>>> o
>>>>>>>>>> d
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <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:DigestM
>>>>>>>>>> e
>>>>>>>>>> t
>>>>>>>>>> h
>>>>>>>>>> o
>>>>>>>>>> d
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <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 <Fr...@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-messa
>>>>>>>>>>> g
>>>>>>>>>>> e
>>>>>>>>>>> -
>>>>>>>>>>> s
>>>>>>>>>>> e
>>>>>>>>>>> c
>>>>>>>>>>> u
>>>>>>>>>>> r
>>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>>>> I
>>>>>>>>>>> d
>>>>>>>>>>> e
>>>>>>>>>>> n
>>>>>>>>>>> t
>>>>>>>>>>> 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-messa
>>>>>>>>>>> g
>>>>>>>>>>> e
>>>>>>>>>>> -
>>>>>>>>>>> s
>>>>>>>>>>> e
>>>>>>>>>>> c
>>>>>>>>>>> u
>>>>>>>>>>> r
>>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>>>> I
>>>>>>>>>>> d
>>>>>>>>>>> e
>>>>>>>>>>> n
>>>>>>>>>>> t
>>>>>>>>>>> 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
>>>>>>>>>>> <Fr...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Thanks a lot.
Could you tell me when the next snapshot will be built then ?
Best Regards.
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: vendredi 20 avril 2012 14:40
To: COURTAULT Francois
Cc: users@cxf.apache.org
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
Right. However, if you are signing something it generally *must* be included in the request, unless in this case where you are using a SecurityTokenReference transform.
> - Could you please give me the JIRA issue number linked to this problem ?
> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
> - Should it be fixed in the next release ? which one ?
I didn't create a JIRA, but the fix has been committed and so it should appear in the next SNAPSHOTS for 2.4.8-SNAPSHOT, 2.5.4-SNAPSHOT or 2.6.1-SNAPSHOT when they get built.
Colm.
On Fri, Apr 20, 2012 at 1:10 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
> Hello,
>
> "Please take care to reply to the mailing list instead of directly to me."
> Understood !
>
> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
> <sp:RecipientToken>
> <wsp:Policy>
> <sp:X509Token
>
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/20
> 0702/IncludeToken/Never">
> <wsp:Policy>
> <sp:RequireThumbprintReference/>
> <sp:WssX509V3Token11/>
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:RecipientToken>
>
> Am I wrong ?
>
> Anyway:
> - Could you please give me the JIRA issue number linked to this problem ?
> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
> - Should it be fixed in the next release ? which one ?
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: vendredi 20 avril 2012 12:27
> To: COURTAULT Francois
> Cc: users@cxf.apache.org
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Hi Francois,
>
> Please take care to reply to the mailing list instead of directly to me.
>
> There is a bug in CXF when validating the OnlySignEntireHeadersAndBody property. In this particular response, the SecurityTokenReference Transform is used to dereference a SecurityTokenReference for signature. The result is a BinarySecurityToken that is not included in the message request. CXF always assumes that the signed Element is in the message request, which is not necessarily true.
>
> I'll merge a fix for this shortly. In the meantime, you can get around the problem by disabling OnlySignEntireHeadersAndBody, or else stop the server signing the signature key.
>
> Colm.
>
> On Fri, Apr 20, 2012 at 10:56 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> Hello,
>>
>> Attached is the SOAP request and also the Response which causes the error.
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: vendredi 20 avril 2012 10:29
>> To: COURTAULT Francois
>> Cc: users@cxf.apache.org
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> Could you attach the SOAP Message that's causing that error?
>>
>> Colm.
>>
>> On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> Hello,
>>>
>>> My tests:
>>> - with no truststore properties in the clientKeystore.properties,
>>> I got the error: The signature or decryption was invalid
>>> - with truststore properties in the clientKeystore.properties, I
>>> got the error: Fault string, and possibly fault code, not set
>>> Caused by: java.lang.NullPointerException
>>> at
>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPol
>>> i
>>> c
>>> yValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPoli
>>> c
>>> y
>>> Validator.java:117)
>>> at
>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPol
>>> i
>>> c
>>> yValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
>>> at
>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingP
>>> o
>>> l
>>> icyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76
>>> )
>>> at
>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.check
>>> B
>>> i
>>> ndingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
>>> at
>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doRes
>>> u
>>> l
>>> ts(PolicyBasedWSS4JInInterceptor.java:556)
>>> at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WS
>>> S
>>> 4
>>> JInInterceptor.java:275)
>>> at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WS
>>> S
>>> 4
>>> JInInterceptor.java:86)
>>> at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercep
>>> t
>>> o
>>> rChain.java:263)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handle
>>> R
>>> e
>>> sponseInternal(HTTPConduit.java:1635)
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handle
>>> R
>>> e
>>> sponse(HTTPConduit.java:1502)
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(
>>> H
>>> T
>>> TPConduit.java:1410)
>>> at
>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:
>>> 5
>>> 6
>>> )
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650
>>> )
>>> at
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEnd
>>> i
>>> n
>>> gInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>> at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercep
>>> t
>>> o
>>> rChain.java:263)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
>>> at
>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:1
>>> 3
>>> 4
>>> )
>>>
>>> Any idea ?
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: jeudi 19 avril 2012 15:19
>>> To: COURTAULT Francois
>>> Cc: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>>>
>>> org.apache.ws.security.crypto.merlin.truststore.file=
>>> org.apache.ws.security.crypto.merlin.truststore.password=
>>>
>>> http://ws.apache.org/wss4j/config.html
>>>
>>> Colm.
>>>
>>> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> Hello again,
>>>>
>>>> Just one remark, before invoking a webservice method, I have those code lines:
>>>> Map<String, Object> ctx = ((BindingProvider)
>>>> port).getRequestContext();
>>>> ctx.put("ws-security.username",
>>>> "wssclientcertificate");
>>>> ctx.put("ws-security.callback-handler",
>>>> ClientX509CB.class.getName());
>>>> ctx.put("ws-security.signature.properties",
>>>> "clientKeystore.properties");
>>>>
>>>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>>>> 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
>>>>
>>>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>>>
>>>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>>>
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: COURTAULT Francois
>>>> Sent: mercredi 18 avril 2012 20:34
>>>> To: users@cxf.apache.org
>>>> Cc: 'coheigea@apache.org'
>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> Hello,
>>>>
>>>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>>>
>>>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>> java.util.logging.ConsoleHandler.formatter =
>>>> java.util.logging.SimpleFormatter
>>>>
>>>> org.apache.cxf.level = FINEST
>>>>
>>>> Again no cxf log ???
>>>>
>>>> Really I need some help in order to solve my issue.
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: mardi 17 avril 2012 11:26
>>>> To: users@cxf.apache.org
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> Try adding in the following dependency:
>>>>
>>>> <groupId>org.slf4j</groupId>
>>>> <artifactId>slf4j-jdk14</artifactId>
>>>>
>>>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>>>
>>>> Colm.
>>>>
>>>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>>>
>>>>> Where in the cxf-logging.properties I have:
>>>>> .level= FINEST
>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>>
>>>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: lundi 16 avril 2012 18:24
>>>>> To: COURTAULT Francois
>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>
>>>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>> 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.
>>>>>> j
>>>>>> k
>>>>>> s
>>>>>>
>>>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKe
>>>>>> y
>>>>>> s
>>>>>> t
>>>>>> o
>>>>>> r
>>>>>> ePassword
>>>>>> 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 <Fr...@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 <Fr...@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#x509
>>>>>>>> t
>>>>>>>> o
>>>>>>>> k
>>>>>>>> e
>>>>>>>> n
>>>>>>>> t
>>>>>>>> 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 <Fr...@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:DigestVal
>>>>>>>>> u
>>>>>>>>> e
>>>>>>>>> >
>>>>>>>>> </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:DigestVal
>>>>>>>>> u
>>>>>>>>> e
>>>>>>>>> >
>>>>>>>>> </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:DigestVal
>>>>>>>>> u
>>>>>>>>> e
>>>>>>>>> >
>>>>>>>>> </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:Si
>>>>>>>>> g
>>>>>>>>> n
>>>>>>>>> a
>>>>>>>>> t
>>>>>>>>> u
>>>>>>>>> r
>>>>>>>>> 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:Digest
>>>>>>>>> M
>>>>>>>>> e
>>>>>>>>> t
>>>>>>>>> h
>>>>>>>>> o
>>>>>>>>> d
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> <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:Digest
>>>>>>>>> M
>>>>>>>>> e
>>>>>>>>> t
>>>>>>>>> h
>>>>>>>>> o
>>>>>>>>> d
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> <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 <Fr...@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-mess
>>>>>>>>>> a
>>>>>>>>>> g
>>>>>>>>>> e
>>>>>>>>>> -
>>>>>>>>>> s
>>>>>>>>>> e
>>>>>>>>>> c
>>>>>>>>>> u
>>>>>>>>>> r
>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Ke
>>>>>>>>>> y
>>>>>>>>>> I
>>>>>>>>>> d
>>>>>>>>>> e
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> 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-mess
>>>>>>>>>> a
>>>>>>>>>> g
>>>>>>>>>> e
>>>>>>>>>> -
>>>>>>>>>> s
>>>>>>>>>> e
>>>>>>>>>> c
>>>>>>>>>> u
>>>>>>>>>> r
>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Ke
>>>>>>>>>> y
>>>>>>>>>> I
>>>>>>>>>> d
>>>>>>>>>> e
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> 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
>>>>>>>>>> <Fr...@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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
Right. However, if you are signing something it generally *must* be
included in the request, unless in this case where you are using a
SecurityTokenReference transform.
> - Could you please give me the JIRA issue number linked to this problem ?
> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
> - Should it be fixed in the next release ? which one ?
I didn't create a JIRA, but the fix has been committed and so it
should appear in the next SNAPSHOTS for 2.4.8-SNAPSHOT, 2.5.4-SNAPSHOT
or 2.6.1-SNAPSHOT when they get built.
Colm.
On Fri, Apr 20, 2012 at 1:10 PM, COURTAULT Francois
<Fr...@gemalto.com> wrote:
> Hello,
>
> "Please take care to reply to the mailing list instead of directly to me."
> Understood !
>
> Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
> <sp:RecipientToken>
> <wsp:Policy>
> <sp:X509Token
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
> <wsp:Policy>
> <sp:RequireThumbprintReference/>
> <sp:WssX509V3Token11/>
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:RecipientToken>
>
> Am I wrong ?
>
> Anyway:
> - Could you please give me the JIRA issue number linked to this problem ?
> - Could you please warn me when you have fixed this issue in order for me to test your modification ?
> - Should it be fixed in the next release ? which one ?
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: vendredi 20 avril 2012 12:27
> To: COURTAULT Francois
> Cc: users@cxf.apache.org
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Hi Francois,
>
> Please take care to reply to the mailing list instead of directly to me.
>
> There is a bug in CXF when validating the OnlySignEntireHeadersAndBody property. In this particular response, the SecurityTokenReference Transform is used to dereference a SecurityTokenReference for signature. The result is a BinarySecurityToken that is not included in the message request. CXF always assumes that the signed Element is in the message request, which is not necessarily true.
>
> I'll merge a fix for this shortly. In the meantime, you can get around the problem by disabling OnlySignEntireHeadersAndBody, or else stop the server signing the signature key.
>
> Colm.
>
> On Fri, Apr 20, 2012 at 10:56 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> Hello,
>>
>> Attached is the SOAP request and also the Response which causes the error.
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: vendredi 20 avril 2012 10:29
>> To: COURTAULT Francois
>> Cc: users@cxf.apache.org
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> Could you attach the SOAP Message that's causing that error?
>>
>> Colm.
>>
>> On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> Hello,
>>>
>>> My tests:
>>> - with no truststore properties in the clientKeystore.properties,
>>> I got the error: The signature or decryption was invalid
>>> - with truststore properties in the clientKeystore.properties, I
>>> got the error: Fault string, and possibly fault code, not set
>>> Caused by: java.lang.NullPointerException
>>> at
>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>>> c
>>> yValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPolic
>>> y
>>> Validator.java:117)
>>> at
>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>>> c
>>> yValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
>>> at
>>> org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPo
>>> l
>>> icyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)
>>> at
>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkB
>>> i
>>> ndingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
>>> at
>>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResu
>>> l
>>> ts(PolicyBasedWSS4JInInterceptor.java:556)
>>> at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>>> 4
>>> JInInterceptor.java:275)
>>> at
>>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>>> 4
>>> JInInterceptor.java:86)
>>> at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>>> o
>>> rChain.java:263)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>>> e
>>> sponseInternal(HTTPConduit.java:1635)
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>>> e
>>> sponse(HTTPConduit.java:1502)
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H
>>> T
>>> TPConduit.java:1410)
>>> at
>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:5
>>> 6
>>> )
>>> at
>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650)
>>> at
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi
>>> n
>>> gInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>> at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>>> o
>>> rChain.java:263)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
>>> at
>>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
>>> at
>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
>>> at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:13
>>> 4
>>> )
>>>
>>> Any idea ?
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: jeudi 19 avril 2012 15:19
>>> To: COURTAULT Francois
>>> Cc: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>>>
>>> org.apache.ws.security.crypto.merlin.truststore.file=
>>> org.apache.ws.security.crypto.merlin.truststore.password=
>>>
>>> http://ws.apache.org/wss4j/config.html
>>>
>>> Colm.
>>>
>>> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> Hello again,
>>>>
>>>> Just one remark, before invoking a webservice method, I have those code lines:
>>>> Map<String, Object> ctx = ((BindingProvider)
>>>> port).getRequestContext();
>>>> ctx.put("ws-security.username",
>>>> "wssclientcertificate");
>>>> ctx.put("ws-security.callback-handler",
>>>> ClientX509CB.class.getName());
>>>> ctx.put("ws-security.signature.properties",
>>>> "clientKeystore.properties");
>>>>
>>>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>>>> 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
>>>>
>>>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>>>
>>>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>>>
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: COURTAULT Francois
>>>> Sent: mercredi 18 avril 2012 20:34
>>>> To: users@cxf.apache.org
>>>> Cc: 'coheigea@apache.org'
>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> Hello,
>>>>
>>>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>>>
>>>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>> java.util.logging.ConsoleHandler.formatter =
>>>> java.util.logging.SimpleFormatter
>>>>
>>>> org.apache.cxf.level = FINEST
>>>>
>>>> Again no cxf log ???
>>>>
>>>> Really I need some help in order to solve my issue.
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: mardi 17 avril 2012 11:26
>>>> To: users@cxf.apache.org
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> Try adding in the following dependency:
>>>>
>>>> <groupId>org.slf4j</groupId>
>>>> <artifactId>slf4j-jdk14</artifactId>
>>>>
>>>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>>>
>>>> Colm.
>>>>
>>>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>> Hello,
>>>>>
>>>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>>>
>>>>> Where in the cxf-logging.properties I have:
>>>>> .level= FINEST
>>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>>
>>>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: lundi 16 avril 2012 18:24
>>>>> To: COURTAULT Francois
>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>>
>>>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>>> 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.
>>>>>> j
>>>>>> k
>>>>>> s
>>>>>>
>>>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKey
>>>>>> s
>>>>>> t
>>>>>> o
>>>>>> r
>>>>>> ePassword
>>>>>> 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 <Fr...@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 <Fr...@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#x509t
>>>>>>>> o
>>>>>>>> k
>>>>>>>> e
>>>>>>>> n
>>>>>>>> t
>>>>>>>> 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 <Fr...@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:DigestValu
>>>>>>>>> e
>>>>>>>>> >
>>>>>>>>> </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:DigestValu
>>>>>>>>> e
>>>>>>>>> >
>>>>>>>>> </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:DigestValu
>>>>>>>>> e
>>>>>>>>> >
>>>>>>>>> </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:Sig
>>>>>>>>> n
>>>>>>>>> a
>>>>>>>>> t
>>>>>>>>> u
>>>>>>>>> r
>>>>>>>>> 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:DigestM
>>>>>>>>> e
>>>>>>>>> t
>>>>>>>>> h
>>>>>>>>> o
>>>>>>>>> d
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> <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:DigestM
>>>>>>>>> e
>>>>>>>>> t
>>>>>>>>> h
>>>>>>>>> o
>>>>>>>>> d
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> <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 <Fr...@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-messa
>>>>>>>>>> g
>>>>>>>>>> e
>>>>>>>>>> -
>>>>>>>>>> s
>>>>>>>>>> e
>>>>>>>>>> c
>>>>>>>>>> u
>>>>>>>>>> r
>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>>> I
>>>>>>>>>> d
>>>>>>>>>> e
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> 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-messa
>>>>>>>>>> g
>>>>>>>>>> e
>>>>>>>>>> -
>>>>>>>>>> s
>>>>>>>>>> e
>>>>>>>>>> c
>>>>>>>>>> u
>>>>>>>>>> r
>>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>>> I
>>>>>>>>>> d
>>>>>>>>>> e
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> 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
>>>>>>>>>> <Fr...@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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello,
"Please take care to reply to the mailing list instead of directly to me."
Understood !
Regarding the "OnlySignEntireHeadersAndBody property", I don't think that the fact that, the BinarySecurityToken is not included in the response, is only linked to this property. According to me, my interpretation is that it is rather linked to this policy section:
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp:Policy>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
Am I wrong ?
Anyway:
- Could you please give me the JIRA issue number linked to this problem ?
- Could you please warn me when you have fixed this issue in order for me to test your modification ?
- Should it be fixed in the next release ? which one ?
Best Regards.
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: vendredi 20 avril 2012 12:27
To: COURTAULT Francois
Cc: users@cxf.apache.org
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Hi Francois,
Please take care to reply to the mailing list instead of directly to me.
There is a bug in CXF when validating the OnlySignEntireHeadersAndBody property. In this particular response, the SecurityTokenReference Transform is used to dereference a SecurityTokenReference for signature. The result is a BinarySecurityToken that is not included in the message request. CXF always assumes that the signed Element is in the message request, which is not necessarily true.
I'll merge a fix for this shortly. In the meantime, you can get around the problem by disabling OnlySignEntireHeadersAndBody, or else stop the server signing the signature key.
Colm.
On Fri, Apr 20, 2012 at 10:56 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
> Hello,
>
> Attached is the SOAP request and also the Response which causes the error.
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: vendredi 20 avril 2012 10:29
> To: COURTAULT Francois
> Cc: users@cxf.apache.org
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Could you attach the SOAP Message that's causing that error?
>
> Colm.
>
> On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> Hello,
>>
>> My tests:
>> - with no truststore properties in the clientKeystore.properties,
>> I got the error: The signature or decryption was invalid
>> - with truststore properties in the clientKeystore.properties, I
>> got the error: Fault string, and possibly fault code, not set
>> Caused by: java.lang.NullPointerException
>> at
>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>> c
>> yValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPolic
>> y
>> Validator.java:117)
>> at
>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPoli
>> c
>> yValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
>> at
>> org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPo
>> l
>> icyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)
>> at
>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkB
>> i
>> ndingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
>> at
>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResu
>> l
>> ts(PolicyBasedWSS4JInInterceptor.java:556)
>> at
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>> 4
>> JInInterceptor.java:275)
>> at
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS
>> 4
>> JInInterceptor.java:86)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>> o
>> rChain.java:263)
>> at
>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
>> at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>> e
>> sponseInternal(HTTPConduit.java:1635)
>> at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
>> e
>> sponse(HTTPConduit.java:1502)
>> at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H
>> T
>> TPConduit.java:1410)
>> at
>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:5
>> 6
>> )
>> at
>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650)
>> at
>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndi
>> n
>> gInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>> o
>> rChain.java:263)
>> at
>> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
>> at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>> at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
>> at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
>> at
>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
>> at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:13
>> 4
>> )
>>
>> Any idea ?
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: jeudi 19 avril 2012 15:19
>> To: COURTAULT Francois
>> Cc: users@cxf.apache.org
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>>
>> org.apache.ws.security.crypto.merlin.truststore.file=
>> org.apache.ws.security.crypto.merlin.truststore.password=
>>
>> http://ws.apache.org/wss4j/config.html
>>
>> Colm.
>>
>> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> Hello again,
>>>
>>> Just one remark, before invoking a webservice method, I have those code lines:
>>> Map<String, Object> ctx = ((BindingProvider)
>>> port).getRequestContext();
>>> ctx.put("ws-security.username",
>>> "wssclientcertificate");
>>> ctx.put("ws-security.callback-handler",
>>> ClientX509CB.class.getName());
>>> ctx.put("ws-security.signature.properties",
>>> "clientKeystore.properties");
>>>
>>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>>> 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
>>>
>>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>>
>>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>>
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: COURTAULT Francois
>>> Sent: mercredi 18 avril 2012 20:34
>>> To: users@cxf.apache.org
>>> Cc: 'coheigea@apache.org'
>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Hello,
>>>
>>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>>
>>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>>> java.util.logging.ConsoleHandler.level = FINEST
>>> java.util.logging.ConsoleHandler.formatter =
>>> java.util.logging.SimpleFormatter
>>>
>>> org.apache.cxf.level = FINEST
>>>
>>> Again no cxf log ???
>>>
>>> Really I need some help in order to solve my issue.
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: mardi 17 avril 2012 11:26
>>> To: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Try adding in the following dependency:
>>>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>slf4j-jdk14</artifactId>
>>>
>>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>>
>>> Colm.
>>>
>>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> Hello,
>>>>
>>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>>
>>>> Where in the cxf-logging.properties I have:
>>>> .level= FINEST
>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>
>>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: lundi 16 avril 2012 18:24
>>>> To: COURTAULT Francois
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>>
>>>> Colm.
>>>>
>>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>> 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.
>>>>> j
>>>>> k
>>>>> s
>>>>>
>>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKey
>>>>> s
>>>>> t
>>>>> o
>>>>> r
>>>>> ePassword
>>>>> 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 <Fr...@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 <Fr...@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#x509t
>>>>>>> o
>>>>>>> k
>>>>>>> e
>>>>>>> n
>>>>>>> t
>>>>>>> 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 <Fr...@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:DigestValu
>>>>>>>> e
>>>>>>>> >
>>>>>>>> </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:DigestValu
>>>>>>>> e
>>>>>>>> >
>>>>>>>> </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:DigestValu
>>>>>>>> e
>>>>>>>> >
>>>>>>>> </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:Sig
>>>>>>>> n
>>>>>>>> a
>>>>>>>> t
>>>>>>>> u
>>>>>>>> r
>>>>>>>> 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:DigestM
>>>>>>>> e
>>>>>>>> t
>>>>>>>> h
>>>>>>>> o
>>>>>>>> d
>>>>>>>> >
>>>>>>>>
>>>>>>>> <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:DigestM
>>>>>>>> e
>>>>>>>> t
>>>>>>>> h
>>>>>>>> o
>>>>>>>> d
>>>>>>>> >
>>>>>>>>
>>>>>>>> <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 <Fr...@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-messa
>>>>>>>>> g
>>>>>>>>> e
>>>>>>>>> -
>>>>>>>>> s
>>>>>>>>> e
>>>>>>>>> c
>>>>>>>>> u
>>>>>>>>> r
>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>> I
>>>>>>>>> d
>>>>>>>>> e
>>>>>>>>> n
>>>>>>>>> t
>>>>>>>>> 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-messa
>>>>>>>>> g
>>>>>>>>> e
>>>>>>>>> -
>>>>>>>>> s
>>>>>>>>> e
>>>>>>>>> c
>>>>>>>>> u
>>>>>>>>> r
>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:Key
>>>>>>>>> I
>>>>>>>>> d
>>>>>>>>> e
>>>>>>>>> n
>>>>>>>>> t
>>>>>>>>> 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
>>>>>>>>> <Fr...@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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francois,
Please take care to reply to the mailing list instead of directly to me.
There is a bug in CXF when validating the OnlySignEntireHeadersAndBody
property. In this particular response, the SecurityTokenReference
Transform is used to dereference a SecurityTokenReference for
signature. The result is a BinarySecurityToken that is not included in
the message request. CXF always assumes that the signed Element is in
the message request, which is not necessarily true.
I'll merge a fix for this shortly. In the meantime, you can get around
the problem by disabling OnlySignEntireHeadersAndBody, or else stop
the server signing the signature key.
Colm.
On Fri, Apr 20, 2012 at 10:56 AM, COURTAULT Francois
<Fr...@gemalto.com> wrote:
> Hello,
>
> Attached is the SOAP request and also the Response which causes the error.
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: vendredi 20 avril 2012 10:29
> To: COURTAULT Francois
> Cc: users@cxf.apache.org
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Could you attach the SOAP Message that's causing that error?
>
> Colm.
>
> On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> Hello,
>>
>> My tests:
>> - with no truststore properties in the clientKeystore.properties, I
>> got the error: The signature or decryption was invalid
>> - with truststore properties in the clientKeystore.properties, I
>> got the error: Fault string, and possibly fault code, not set
>> Caused by: java.lang.NullPointerException
>> at
>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPolic
>> yValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPolicy
>> Validator.java:117)
>> at
>> org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPolic
>> yValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
>> at
>> org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPol
>> icyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)
>> at
>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkBi
>> ndingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
>> at
>> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResul
>> ts(PolicyBasedWSS4JInInterceptor.java:556)
>> at
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4
>> JInInterceptor.java:275)
>> at
>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4
>> JInInterceptor.java:86)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>> rChain.java:263)
>> at
>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
>> at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRe
>> sponseInternal(HTTPConduit.java:1635)
>> at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRe
>> sponse(HTTPConduit.java:1502)
>> at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HT
>> TPConduit.java:1410)
>> at
>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56
>> )
>> at
>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650)
>> at
>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndin
>> gInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>> rChain.java:263)
>> at
>> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
>> at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
>> at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
>> at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
>> at
>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
>> at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134
>> )
>>
>> Any idea ?
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: jeudi 19 avril 2012 15:19
>> To: COURTAULT Francois
>> Cc: users@cxf.apache.org
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>>
>> org.apache.ws.security.crypto.merlin.truststore.file=
>> org.apache.ws.security.crypto.merlin.truststore.password=
>>
>> http://ws.apache.org/wss4j/config.html
>>
>> Colm.
>>
>> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> Hello again,
>>>
>>> Just one remark, before invoking a webservice method, I have those code lines:
>>> Map<String, Object> ctx = ((BindingProvider)
>>> port).getRequestContext();
>>> ctx.put("ws-security.username",
>>> "wssclientcertificate");
>>> ctx.put("ws-security.callback-handler",
>>> ClientX509CB.class.getName());
>>> ctx.put("ws-security.signature.properties",
>>> "clientKeystore.properties");
>>>
>>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>>> 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
>>>
>>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>>
>>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>>
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: COURTAULT Francois
>>> Sent: mercredi 18 avril 2012 20:34
>>> To: users@cxf.apache.org
>>> Cc: 'coheigea@apache.org'
>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Hello,
>>>
>>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>>
>>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>>> java.util.logging.ConsoleHandler.level = FINEST
>>> java.util.logging.ConsoleHandler.formatter =
>>> java.util.logging.SimpleFormatter
>>>
>>> org.apache.cxf.level = FINEST
>>>
>>> Again no cxf log ???
>>>
>>> Really I need some help in order to solve my issue.
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: mardi 17 avril 2012 11:26
>>> To: users@cxf.apache.org
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Try adding in the following dependency:
>>>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>slf4j-jdk14</artifactId>
>>>
>>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>>
>>> Colm.
>>>
>>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> Hello,
>>>>
>>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>>
>>>> Where in the cxf-logging.properties I have:
>>>> .level= FINEST
>>>> java.util.logging.ConsoleHandler.level = FINEST
>>>>
>>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: lundi 16 avril 2012 18:24
>>>> To: COURTAULT Francois
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>>
>>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>>
>>>> Colm.
>>>>
>>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>>> 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.
>>>>> j
>>>>> k
>>>>> s
>>>>>
>>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeys
>>>>> t
>>>>> o
>>>>> r
>>>>> ePassword
>>>>> 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 <Fr...@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 <Fr...@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#x509to
>>>>>>> k
>>>>>>> e
>>>>>>> n
>>>>>>> t
>>>>>>> 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 <Fr...@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:Sign
>>>>>>>> a
>>>>>>>> t
>>>>>>>> u
>>>>>>>> r
>>>>>>>> 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:DigestMe
>>>>>>>> t
>>>>>>>> h
>>>>>>>> o
>>>>>>>> d
>>>>>>>> >
>>>>>>>>
>>>>>>>> <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:DigestMe
>>>>>>>> t
>>>>>>>> h
>>>>>>>> o
>>>>>>>> d
>>>>>>>> >
>>>>>>>>
>>>>>>>> <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 <Fr...@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-messag
>>>>>>>>> e
>>>>>>>>> -
>>>>>>>>> s
>>>>>>>>> e
>>>>>>>>> c
>>>>>>>>> u
>>>>>>>>> r
>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyI
>>>>>>>>> d
>>>>>>>>> e
>>>>>>>>> n
>>>>>>>>> t
>>>>>>>>> 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-messag
>>>>>>>>> e
>>>>>>>>> -
>>>>>>>>> s
>>>>>>>>> e
>>>>>>>>> c
>>>>>>>>> u
>>>>>>>>> r
>>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyI
>>>>>>>>> d
>>>>>>>>> e
>>>>>>>>> n
>>>>>>>>> t
>>>>>>>>> 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
>>>>>>>>> <Fr...@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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Could you attach the SOAP Message that's causing that error?
Colm.
On Thu, Apr 19, 2012 at 4:38 PM, COURTAULT Francois
<Fr...@gemalto.com> wrote:
> Hello,
>
> My tests:
> - with no truststore properties in the clientKeystore.properties, I got the error: The signature or decryption was invalid
> - with truststore properties in the clientKeystore.properties, I got the error: Fault string, and possibly fault code, not set
> Caused by: java.lang.NullPointerException
> at org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPolicyValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPolicyValidator.java:117)
> at org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPolicyValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
> at org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPolicyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)
> at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkBindingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
> at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResults(PolicyBasedWSS4JInInterceptor.java:556)
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:275)
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:86)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1635)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1502)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1410)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
>
> Any idea ?
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: jeudi 19 avril 2012 15:19
> To: COURTAULT Francois
> Cc: users@cxf.apache.org
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
>
> org.apache.ws.security.crypto.merlin.truststore.file=
> org.apache.ws.security.crypto.merlin.truststore.password=
>
> http://ws.apache.org/wss4j/config.html
>
> Colm.
>
> On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> Hello again,
>>
>> Just one remark, before invoking a webservice method, I have those code lines:
>> Map<String, Object> ctx = ((BindingProvider)
>> port).getRequestContext();
>> ctx.put("ws-security.username",
>> "wssclientcertificate");
>> ctx.put("ws-security.callback-handler",
>> ClientX509CB.class.getName());
>> ctx.put("ws-security.signature.properties",
>> "clientKeystore.properties");
>>
>> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
>> 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
>>
>> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>>
>> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>>
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: COURTAULT Francois
>> Sent: mercredi 18 avril 2012 20:34
>> To: users@cxf.apache.org
>> Cc: 'coheigea@apache.org'
>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> Hello,
>>
>> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>>
>> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
>> java.util.logging.ConsoleHandler.level = FINEST
>> java.util.logging.ConsoleHandler.formatter =
>> java.util.logging.SimpleFormatter
>>
>> org.apache.cxf.level = FINEST
>>
>> Again no cxf log ???
>>
>> Really I need some help in order to solve my issue.
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: mardi 17 avril 2012 11:26
>> To: users@cxf.apache.org
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> Try adding in the following dependency:
>>
>> <groupId>org.slf4j</groupId>
>> <artifactId>slf4j-jdk14</artifactId>
>>
>> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>>
>> Colm.
>>
>> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> Hello,
>>>
>>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>>
>>> Where in the cxf-logging.properties I have:
>>> .level= FINEST
>>> java.util.logging.ConsoleHandler.level = FINEST
>>>
>>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: lundi 16 avril 2012 18:24
>>> To: COURTAULT Francois
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>>
>>> Colm.
>>>
>>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>>> 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.
>>>> j
>>>> k
>>>> s
>>>>
>>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeyst
>>>> o
>>>> r
>>>> ePassword
>>>> 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 <Fr...@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 <Fr...@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#x509tok
>>>>>> e
>>>>>> n
>>>>>> t
>>>>>> 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 <Fr...@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:Signa
>>>>>>> t
>>>>>>> u
>>>>>>> r
>>>>>>> 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:DigestMet
>>>>>>> h
>>>>>>> o
>>>>>>> d
>>>>>>> >
>>>>>>>
>>>>>>> <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:DigestMet
>>>>>>> h
>>>>>>> o
>>>>>>> d
>>>>>>> >
>>>>>>>
>>>>>>> <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 <Fr...@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
>>>>>>>> -
>>>>>>>> s
>>>>>>>> e
>>>>>>>> c
>>>>>>>> u
>>>>>>>> r
>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyId
>>>>>>>> e
>>>>>>>> n
>>>>>>>> t
>>>>>>>> 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
>>>>>>>> -
>>>>>>>> s
>>>>>>>> e
>>>>>>>> c
>>>>>>>> u
>>>>>>>> r
>>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyId
>>>>>>>> e
>>>>>>>> n
>>>>>>>> t
>>>>>>>> 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
>>>>>>>> <Fr...@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
>>>
>>>
>>>
>>> --
>>> 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
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello,
My tests:
- with no truststore properties in the clientKeystore.properties, I got the error: The signature or decryption was invalid
- with truststore properties in the clientKeystore.properties, I got the error: Fault string, and possibly fault code, not set
Caused by: java.lang.NullPointerException
at org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPolicyValidator.validateEntireHeaderAndBodySignatures(AbstractBindingPolicyValidator.java:117)
at org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPolicyValidator.checkProperties(AbstractBindingPolicyValidator.java:198)
at org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPolicyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)
at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkBindingCoverage(PolicyBasedWSS4JInInterceptor.java:669)
at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResults(PolicyBasedWSS4JInInterceptor.java:556)
at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:275)
at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:86)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1635)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1502)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1410)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:650)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
Any idea ?
Best Regards.
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: jeudi 19 avril 2012 15:19
To: COURTAULT Francois
Cc: users@cxf.apache.org
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
If you have access to the CA cert that issues the service provider's certificate, then you can put it in a keystore and reference it in the client's KeyStore properties file using:
org.apache.ws.security.crypto.merlin.truststore.file=
org.apache.ws.security.crypto.merlin.truststore.password=
http://ws.apache.org/wss4j/config.html
Colm.
On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois <Fr...@gemalto.com> wrote:
> Hello again,
>
> Just one remark, before invoking a webservice method, I have those code lines:
> Map<String, Object> ctx = ((BindingProvider)
> port).getRequestContext();
> ctx.put("ws-security.username",
> "wssclientcertificate");
> ctx.put("ws-security.callback-handler",
> ClientX509CB.class.getName());
> ctx.put("ws-security.signature.properties",
> "clientKeystore.properties");
>
> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
> 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
>
> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>
> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>
>
> Best Regards.
>
> -----Original Message-----
> From: COURTAULT Francois
> Sent: mercredi 18 avril 2012 20:34
> To: users@cxf.apache.org
> Cc: 'coheigea@apache.org'
> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Hello,
>
> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>
> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
> java.util.logging.ConsoleHandler.level = FINEST
> java.util.logging.ConsoleHandler.formatter =
> java.util.logging.SimpleFormatter
>
> org.apache.cxf.level = FINEST
>
> Again no cxf log ???
>
> Really I need some help in order to solve my issue.
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: mardi 17 avril 2012 11:26
> To: users@cxf.apache.org
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Try adding in the following dependency:
>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-jdk14</artifactId>
>
> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>
> Colm.
>
> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> Hello,
>>
>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>
>> Where in the cxf-logging.properties I have:
>> .level= FINEST
>> java.util.logging.ConsoleHandler.level = FINEST
>>
>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: lundi 16 avril 2012 18:24
>> To: COURTAULT Francois
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>
>> Colm.
>>
>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> 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.
>>> j
>>> k
>>> s
>>>
>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeyst
>>> o
>>> r
>>> ePassword
>>> 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 <Fr...@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 <Fr...@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#x509tok
>>>>> e
>>>>> n
>>>>> t
>>>>> 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 <Fr...@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:Signa
>>>>>> t
>>>>>> u
>>>>>> r
>>>>>> 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:DigestMet
>>>>>> h
>>>>>> o
>>>>>> d
>>>>>> >
>>>>>>
>>>>>> <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:DigestMet
>>>>>> h
>>>>>> o
>>>>>> d
>>>>>> >
>>>>>>
>>>>>> <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 <Fr...@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
>>>>>>> -
>>>>>>> s
>>>>>>> e
>>>>>>> c
>>>>>>> u
>>>>>>> r
>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyId
>>>>>>> e
>>>>>>> n
>>>>>>> t
>>>>>>> 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
>>>>>>> -
>>>>>>> s
>>>>>>> e
>>>>>>> c
>>>>>>> u
>>>>>>> r
>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyId
>>>>>>> e
>>>>>>> n
>>>>>>> t
>>>>>>> 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
>>>>>>> <Fr...@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
>>
>>
>>
>> --
>> 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
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
If you have access to the CA cert that issues the service provider's
certificate, then you can put it in a keystore and reference it in the
client's KeyStore properties file using:
org.apache.ws.security.crypto.merlin.truststore.file=
org.apache.ws.security.crypto.merlin.truststore.password=
http://ws.apache.org/wss4j/config.html
Colm.
On Thu, Apr 19, 2012 at 9:32 AM, COURTAULT Francois
<Fr...@gemalto.com> wrote:
> Hello again,
>
> Just one remark, before invoking a webservice method, I have those code lines:
> Map<String, Object> ctx = ((BindingProvider) port).getRequestContext();
> ctx.put("ws-security.username", "wssclientcertificate");
> ctx.put("ws-security.callback-handler", ClientX509CB.class.getName());
> ctx.put("ws-security.signature.properties", "clientKeystore.properties");
>
> And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
> 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
>
> The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
>
> How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
>
>
> Best Regards.
>
> -----Original Message-----
> From: COURTAULT Francois
> Sent: mercredi 18 avril 2012 20:34
> To: users@cxf.apache.org
> Cc: 'coheigea@apache.org'
> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Hello,
>
> Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
>
> So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
> java.util.logging.ConsoleHandler.level = FINEST java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
>
> org.apache.cxf.level = FINEST
>
> Again no cxf log ???
>
> Really I need some help in order to solve my issue.
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: mardi 17 avril 2012 11:26
> To: users@cxf.apache.org
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> Try adding in the following dependency:
>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-jdk14</artifactId>
>
> Failing that take a look at any of the STS systests in CXF to see how logging works there.
>
> Colm.
>
> On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> Hello,
>>
>> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>>
>> Where in the cxf-logging.properties I have:
>> .level= FINEST
>> java.util.logging.ConsoleHandler.level = FINEST
>>
>> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: lundi 16 avril 2012 18:24
>> To: COURTAULT Francois
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>>
>> Colm.
>>
>> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>>> 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.j
>>> k
>>> s
>>>
>>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeysto
>>> r
>>> ePassword
>>> 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 <Fr...@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 <Fr...@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#x509toke
>>>>> n
>>>>> t
>>>>> 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 <Fr...@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:Signat
>>>>>> u
>>>>>> r
>>>>>> 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:DigestMeth
>>>>>> o
>>>>>> d
>>>>>> >
>>>>>>
>>>>>> <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:DigestMeth
>>>>>> o
>>>>>> d
>>>>>> >
>>>>>>
>>>>>> <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 <Fr...@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-
>>>>>>> s
>>>>>>> e
>>>>>>> c
>>>>>>> u
>>>>>>> r
>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIde
>>>>>>> n
>>>>>>> t
>>>>>>> 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-
>>>>>>> s
>>>>>>> e
>>>>>>> c
>>>>>>> u
>>>>>>> r
>>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIde
>>>>>>> n
>>>>>>> t
>>>>>>> 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
>>>>>>> <Fr...@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
>>
>>
>>
>> --
>> 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
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
Hello again,
Just one remark, before invoking a webservice method, I have those code lines:
Map<String, Object> ctx = ((BindingProvider) port).getRequestContext();
ctx.put("ws-security.username", "wssclientcertificate");
ctx.put("ws-security.callback-handler", ClientX509CB.class.getName());
ctx.put("ws-security.signature.properties", "clientKeystore.properties");
And the content of the clientKeystore.properties file is (useful to sign the SOAP request):
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
The above information is useful to sign the SOAP request but with, the policy used, the response is signed by the server: this why now I didn't get any error from the server but, on the client side, I need to have a configuration which help me to verify the server signature.
How can I do that because my code doesn't refer at all to the server certificate which seems, according to me, mandatory in order to be able to perform this server signature verification at the client side ?
Best Regards.
-----Original Message-----
From: COURTAULT Francois
Sent: mercredi 18 avril 2012 20:34
To: users@cxf.apache.org
Cc: 'coheigea@apache.org'
Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Hello,
Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
So I have tried to adapt my previous logging config file, cxf-logging.properties with the content:
java.util.logging.ConsoleHandler.level = FINEST java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
org.apache.cxf.level = FINEST
Again no cxf log ???
Really I need some help in order to solve my issue.
Best Regards.
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: mardi 17 avril 2012 11:26
To: users@cxf.apache.org
Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Try adding in the following dependency:
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
Failing that take a look at any of the STS systests in CXF to see how logging works there.
Colm.
On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
> Hello,
>
> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/ in the VM arguments.
>
> Where in the cxf-logging.properties I have:
> .level= FINEST
> java.util.logging.ConsoleHandler.level = FINEST
>
> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: lundi 16 avril 2012 18:24
> To: COURTAULT Francois
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>
> Colm.
>
> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> 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.j
>> k
>> s
>>
>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeysto
>> r
>> ePassword
>> 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 <Fr...@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 <Fr...@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#x509toke
>>>> n
>>>> t
>>>> 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 <Fr...@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:Signat
>>>>> u
>>>>> r
>>>>> 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:DigestMeth
>>>>> o
>>>>> d
>>>>> >
>>>>>
>>>>> <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:DigestMeth
>>>>> o
>>>>> d
>>>>> >
>>>>>
>>>>> <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 <Fr...@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-
>>>>>> s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIde
>>>>>> n
>>>>>> t
>>>>>> 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-
>>>>>> s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIde
>>>>>> n
>>>>>> t
>>>>>> 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
>>>>>> <Fr...@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
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Try adding in the following dependency:
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
Failing that take a look at any of the STS systests in CXF to see how
logging works there.
Colm.
On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois
<Fr...@gemalto.com> wrote:
> Hello,
>
> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/cxf-logging.properties in the VM arguments.
>
> Where in the cxf-logging.properties I have:
> .level= FINEST
> java.util.logging.ConsoleHandler.level = FINEST
>
> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: lundi 16 avril 2012 18:24
> To: COURTAULT Francois
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> The best way to find out what's going on is to turn logging up to FINEST, and see whether it's a problem with trust verification, or digest comparison.
>
> Colm.
>
> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Fr...@gemalto.com> wrote:
>> 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.jk
>> s
>>
>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeystor
>> ePassword
>> 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 <Fr...@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 <Fr...@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#x509token
>>>> t
>>>> 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 <Fr...@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:Signatu
>>>>> r
>>>>> 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:DigestMetho
>>>>> d
>>>>> >
>>>>>
>>>>> <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:DigestMetho
>>>>> d
>>>>> >
>>>>>
>>>>> <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 <Fr...@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-s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIden
>>>>>> t
>>>>>> 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-s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIden
>>>>>> t
>>>>>> 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
>>>>>> <Fr...@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
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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 <Fr...@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 <Fr...@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 <Fr...@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 <Fr...@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
>>>> <Fr...@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
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
> - *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
<Fr...@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 <Fr...@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#x509tokenty
>> 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 <Fr...@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:Signature
>>> 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 <Fr...@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-sec
>>>> u
>>>> r
>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdenti
>>>> 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-sec
>>>> u
>>>> r
>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdenti
>>>> 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
>>>> <Fr...@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
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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#x509tokentypes
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 <Fr...@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:SignatureM
> 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 <Fr...@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-secu
>> r
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentif
>> 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-secu
>> r
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentif
>> 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
>> <Fr...@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
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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#x509tokentypes
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 <Fr...@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:SignatureM
> 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 <Fr...@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-secu
>> r
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentif
>> 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-secu
>> r
>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentif
>> 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
>> <Fr...@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
RE: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by COURTAULT Francois <Fr...@gemalto.com>.
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:SignatureMethod>
<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 <Fr...@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-secur
> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifi
> 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-secur
> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifi
> 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
> <Fr...@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
Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Posted by Colm O hEigeartaigh <co...@apache.org>.
> 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
<Fr...@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-security-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifier>
> </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-security-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIdentifier>
> </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
> <Fr...@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