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