Here it is then: https://issues.apache.org/jira/browse/CXF-4254
Colm. On Fri, Apr 20, 2012 at 1:50 PM, Gary Gregory <ggreg...@rocketsoftware.com> wrote: > On Apr 20, 2012, at 8:39, "Colm O hEigeartaigh" <cohei...@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 >> <francois.courta...@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:cohei...@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 >>> <francois.courta...@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:cohei...@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 >>>> <francois.courta...@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:cohei...@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 >>>>> <francois.courta...@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: '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=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: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#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 >>>>>>>>>> <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: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: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-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: '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 >>>>> >>>>> >>>>> >>>>> -- >>>>> 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
