You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Cyril <co...@gmail.com> on 2013/12/19 18:45:32 UTC
CXF-Metro WS-SecureConversation Interop issue (CXF client to Metro service)
Hello,
I am trying to have a WS-SecureConversation between a CXF client - version
2.7.6 - talking to a Metro service with WS-SecureConversation (over SSL
TransportBinding). When CXF makes the final service call with the
SecurityContextToken in the security header, the service replies a SOAP
fault "Invalid Security Header". The service logs say the Signature
Verification for Signature with ID SIG-4 failed. I am trying to investigate
more on the service side what is wrong with the signature. However, I
noticed the following exceptions in CXF in FINE log level:
Dec 19, 2013 6:37:08 PM
org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
FINE: An exception was thrown when verifying that the effective policy for
this request was satisfied. However, this exception will not result in a
fault. The exception raised is: org.apache.cxf.ws.policy.PolicyException:
These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
Could this be an issue? Better ideas?
I have attached the service WSDL, and the CXF client (Spring) configuration
and debug logs with the requests/responses.
Thanks for any help.
Regards,
Cyril
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Cyril,
This is a bug in CXF which I've fixed:
https://issues.apache.org/jira/browse/CXF-5497
Your testcase works with CXF 2.7.9-SNAPSHOT for both 128 and 256 bits.
Colm.
On Fri, Jan 17, 2014 at 12:02 AM, Cyril <co...@gmail.com> wrote:
> Hello,
> the good news is that your solution works!... when the algorithm suite in
> the BootstrapPolicy is Basic128. If I change it back to Basic256 like
> originally, it doesn't work, even with keysize changed to 256 in the
> ws-security.sts.client property. I noticed that when CXF sends a
> <wst:KeySize>128</wst:KeySize> in the first request (with Basic128 in
> bootstrap policy), i.e. the RST request, the test case succeeds; whereas
> for the failing cases - with Basic256 in bootstrap policy or if the
> ws.security.sts.client keysize property is not set - this KeySize element
> is missing from the RST message. Is there a reason why CXF would not send
> it for keysize 256 as well?
>
> This is already a great leap forward, thanks a lot. Yet, it would be
> greater if I could make this work for Basic256 algorithm in the secure
> conversation bootstrap policy. This can be tested with the test case I sent
> previously, by defining Basic256 as algorithm suite of the
> <BootstrapPolicy> element in the WSDL located at
> WEB-INF/wsdl/PingService.wsdl within the jaxws-sc.war in src/test/resources.
>
> Thanks.
>
> Regards,
> Cyril
>
>
> On Wed, Jan 15, 2014 at 12:24 PM, Colm O hEigeartaigh <coheigea@apache.org
> > wrote:
>
>> Hi Cyril,
>>
>> Thanks for the test-case. The problem is that CXF is using 256 bits as the
>> keysize, whereas Metro is using 128 bits, hence the signature verification
>> error. You can adjust CXF by editing the client-cxf.xml file in your
>> project, + adding the following jaxws:property to the client bean:
>>
>> <entry key="ws-security.sts.client">
>> <bean class="org.apache.cxf.ws.security.trust.STSClient">
>> <constructor-arg ref="cxf"/>
>> <property name="keySize" value="128" />
>> </bean>
>> </entry>
>>
>> Let me know if this doesn't work.
>>
>> Colm.
>>
>>
>> On Tue, Jan 14, 2014 at 12:53 AM, Cyril <co...@gmail.com> wrote:
>>
>> > Hello Colm,
>> > please find the test case in the zip uploaded here (file size was
>> rejected
>> > by the mail server):
>> >
>> >
>> https://drive.google.com/file/d/0Bx-J-1KEN3jNLWcwVXQ5c3daaGM/edit?usp=sharing
>> > Filename: cxf-client-metro-wssc-interop-test.zip
>> >
>> > It is a maven project with a JUnit test case that launches the Metro
>> > service in an embedded Jetty, then runs the CXF client against it. Make
>> > sure the port 8443 is available locally, or change the port in file
>> > src/test/resources/cxf-client.xml (jaxws:client element) and class
>> > simple.client.PingServiceClientTest. If this is not what you expect,
>> please
>> > tell me, as I am not used to create such test cases.
>> >
>> > Thanks for reviewing, and sorry for my late reply.
>> >
>> > Regards,
>> > Cyril
>> >
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Cyril <co...@gmail.com>.
Hello,
the good news is that your solution works!... when the algorithm suite in
the BootstrapPolicy is Basic128. If I change it back to Basic256 like
originally, it doesn't work, even with keysize changed to 256 in the
ws-security.sts.client property. I noticed that when CXF sends a
<wst:KeySize>128</wst:KeySize> in the first request (with Basic128 in
bootstrap policy), i.e. the RST request, the test case succeeds; whereas
for the failing cases - with Basic256 in bootstrap policy or if the
ws.security.sts.client keysize property is not set - this KeySize element
is missing from the RST message. Is there a reason why CXF would not send
it for keysize 256 as well?
This is already a great leap forward, thanks a lot. Yet, it would be
greater if I could make this work for Basic256 algorithm in the secure
conversation bootstrap policy. This can be tested with the test case I sent
previously, by defining Basic256 as algorithm suite of the
<BootstrapPolicy> element in the WSDL located at
WEB-INF/wsdl/PingService.wsdl within the jaxws-sc.war in src/test/resources.
Thanks.
Regards,
Cyril
On Wed, Jan 15, 2014 at 12:24 PM, Colm O hEigeartaigh
<co...@apache.org>wrote:
> Hi Cyril,
>
> Thanks for the test-case. The problem is that CXF is using 256 bits as the
> keysize, whereas Metro is using 128 bits, hence the signature verification
> error. You can adjust CXF by editing the client-cxf.xml file in your
> project, + adding the following jaxws:property to the client bean:
>
> <entry key="ws-security.sts.client">
> <bean class="org.apache.cxf.ws.security.trust.STSClient">
> <constructor-arg ref="cxf"/>
> <property name="keySize" value="128" />
> </bean>
> </entry>
>
> Let me know if this doesn't work.
>
> Colm.
>
>
> On Tue, Jan 14, 2014 at 12:53 AM, Cyril <co...@gmail.com> wrote:
>
> > Hello Colm,
> > please find the test case in the zip uploaded here (file size was
> rejected
> > by the mail server):
> >
> >
> https://drive.google.com/file/d/0Bx-J-1KEN3jNLWcwVXQ5c3daaGM/edit?usp=sharing
> > Filename: cxf-client-metro-wssc-interop-test.zip
> >
> > It is a maven project with a JUnit test case that launches the Metro
> > service in an embedded Jetty, then runs the CXF client against it. Make
> > sure the port 8443 is available locally, or change the port in file
> > src/test/resources/cxf-client.xml (jaxws:client element) and class
> > simple.client.PingServiceClientTest. If this is not what you expect,
> please
> > tell me, as I am not used to create such test cases.
> >
> > Thanks for reviewing, and sorry for my late reply.
> >
> > Regards,
> > Cyril
> >
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Cyril,
Thanks for the test-case. The problem is that CXF is using 256 bits as the
keysize, whereas Metro is using 128 bits, hence the signature verification
error. You can adjust CXF by editing the client-cxf.xml file in your
project, + adding the following jaxws:property to the client bean:
<entry key="ws-security.sts.client">
<bean class="org.apache.cxf.ws.security.trust.STSClient">
<constructor-arg ref="cxf"/>
<property name="keySize" value="128" />
</bean>
</entry>
Let me know if this doesn't work.
Colm.
On Tue, Jan 14, 2014 at 12:53 AM, Cyril <co...@gmail.com> wrote:
> Hello Colm,
> please find the test case in the zip uploaded here (file size was rejected
> by the mail server):
>
> https://drive.google.com/file/d/0Bx-J-1KEN3jNLWcwVXQ5c3daaGM/edit?usp=sharing
> Filename: cxf-client-metro-wssc-interop-test.zip
>
> It is a maven project with a JUnit test case that launches the Metro
> service in an embedded Jetty, then runs the CXF client against it. Make
> sure the port 8443 is available locally, or change the port in file
> src/test/resources/cxf-client.xml (jaxws:client element) and class
> simple.client.PingServiceClientTest. If this is not what you expect, please
> tell me, as I am not used to create such test cases.
>
> Thanks for reviewing, and sorry for my late reply.
>
> Regards,
> Cyril
>
>
> On Thu, Jan 9, 2014 at 2:48 PM, Colm O hEigeartaigh <coheigea@apache.org
> >wrote:
>
> >
> > Hi Cyril,
> >
> > Could you create a test-case that reproduces the problem + I will take a
> > look?
> >
> > Colm.
> >
> >
> > On Tue, Jan 7, 2014 at 3:28 PM, Cyril <co...@gmail.com> wrote:
> >
> >> Hello,
> >> I tried with Basic128 to no avail. Please find the client/server logs in
> >> attachment. I have improved the Metro server logs a bit. In particular,
> I
> >> enabled HTTP message dumping there as well to make it easier to
> correlate
> >> client logs with server logs. Besides, you mentioned the fact that the
> >> client and service might be deriving keys differently. Yet, I have no
> >> <RequireDerivedKeys> assertion in the WSDL. Should there be some key
> >> derivation process happening anyway? I looked for derivation-related
> stuff
> >> in the logs and did not find any. But maybe logs are not detailed
> enough.
> >>
> >> Thanks for your help.
> >>
> >> Regards,
> >> Cyril
> >>
> >>
> >> On Tue, Jan 7, 2014 at 10:58 AM, Colm O hEigeartaigh <
> coheigea@apache.org
> >> > wrote:
> >>
> >>>
> >>> Ok thanks. Could you try changing the two "Basic256" policies in the
> >>> WSDL to "Basic128" + try again to see if it works?
> >>>
> >>> Colm.
> >>>
> >>>
> >>> On Mon, Jan 6, 2014 at 5:09 PM, Cyril <co...@gmail.com> wrote:
> >>>
> >>>> Hello,
> >>>> I've tried again, with CXF 2.7.8 this time. Please find the logs in
> >>>> attachment (zip). The zip contains:
> >>>> - The debug logging on the Metro service side (any log from classes in
> >>>> packages com.sun.xml.ws.*): metro_wsp_requested by_cxf_wsc.log
> >>>> - The corresponding CXF client debug logs: cxf_client.log.
> >>>>
> >>>> Regards,
> >>>> Cyril
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jan 3, 2014 at 12:50 PM, Colm O hEigeartaigh <
> >>>> coheigea@apache.org> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> Could you try with CXF 2.7.8 to see if it works? Could you also send
> >>>>> debug
> >>>>> logging of the service side? It looks like the problem might be that
> >>>>> the
> >>>>> client + service might be deriving the secret keys in different
> ways. I
> >>>>> fixed some issues on trunk relating to this, but I'm not sure if
> there
> >>>>> were
> >>>>> any fixes in 2.7.x or not.
> >>>>>
> >>>>> Colm.
> >>>>>
> >>>>>
> >>>>> On Thu, Dec 26, 2013 at 1:08 PM, Cyril <co...@gmail.com> wrote:
> >>>>>
> >>>>> > Hi Dennis,
> >>>>> >
> >>>>> > Yes, the issue occurs only when calling the service after the
> >>>>> security
> >>>>> > context token has been successfully obtained.
> >>>>> >
> >>>>> > 1) If you look for "Outbound Message" from the beginning of the CXF
> >>>>> client
> >>>>> > log attached, you'll find the first client request which is the
> >>>>> RST/SCT
> >>>>> > (ID: 1):
> >>>>> >
> >>>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
> >>>>> "><soap:Header><Action
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing">
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT
> >>>>> </Action><MessageID
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing
> >>>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing">
> >>>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
> >>>>> > http://www.w3.org/2005/08/addressing"><Address>
> >>>>> > http://www.w3.org/2005/08/addressing/anonymous
> >>>>> </Address></ReplyTo><wsse:Security
> >>>>> > xmlns:wsse="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >>>>> "
> >>>>> > xmlns:wsu="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> >>>>> "
> >>>>> > soap:mustUnderstand="true"><wsu:Timestamp
> >>>>> >
> >>>>>
> wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
> >>>>> >
> >>>>>
> wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
> >>>>> > Type="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> >>>>>
> ">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
> >>>>> > xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust
> >>>>> "><wst:RequestType>
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
> >>>>> </wst:RequestType><wsp:AppliesTo
> >>>>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
> >>>>> > xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
> >>>>> > https://localhost:8443/jaxws-sc/simple
> >>>>> </wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
> >>>>> > xmlns:wsu="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> >>>>> >
> >>>>>
> "><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> >>>>> </wst:TokenType><wst:Entropy><wst:BinarySecret
> >>>>> > Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
> >>>>> >
> >>>>>
> ">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
> >>>>> >
> >>>>>
> </wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
> >>>>> >
> >>>>> > 2) Then look for "Inbound Message" : the Metro service response,
> >>>>> which is
> >>>>> > the RSTR/SCT (HTTP status code 200). So far so good:
> >>>>> >
> >>>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
> >>>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
> >>>>> > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd
> "
> >>>>> > xmlns:wsse="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >>>>> "
> >>>>> > xmlns:wsu="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> >>>>> "
> >>>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action
> >>>>> xmlns="
> >>>>> > http://www.w3.org/2005/08/addressing">
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT
> >>>>> </Action><MessageID
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing
> >>>>> ">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing
> >>>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing">
> >>>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
> >>>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
> >>>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
> >>>>> > xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/"
> >>>>> >
> >>>>>
> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
> >>>>> > xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust"
> xmlns:ns6="
> >>>>> > http://www.w3.org/2005/08/addressing" xmlns:ns7="
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
> >>>>> > http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"
> >>>>> xmlns:ns9="
> >>>>> > http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
> >>>>> > http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
> >>>>> > http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> >>>>> </ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
> >>>>> >
> >>>>>
> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
> >>>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> >>>>>
> "/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
> >>>>> > URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> >>>>> >
> >>>>>
> "/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
> >>>>> </ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
> >>>>> > ns5:Type="BinarySecret"><ns5:BinarySecret Type="
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
> >>>>> >
> >>>>>
> ">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
> >>>>> >
> >>>>> > 3) Then the client request with the SCT to the application (ID:
> 2):
> >>>>> >
> >>>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
> >>>>> "><soap:Header><Action
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing">
> http://xmlsoap.org/Ping
> >>>>> </Action><MessageID
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing
> >>>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing">
> >>>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
> >>>>> > http://www.w3.org/2005/08/addressing"><Address>
> >>>>> > http://www.w3.org/2005/08/addressing/anonymous
> >>>>> </Address></ReplyTo><wsse:Security
> >>>>> > xmlns:wsse="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >>>>> "
> >>>>> > xmlns:wsu="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> >>>>> "
> >>>>> > soap:mustUnderstand="true"><wsu:Timestamp
> >>>>> >
> >>>>>
> wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
> >>>>> > xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> >>>>> "
> >>>>> >
> >>>>>
> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
> >>>>> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
> >>>>> > Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
> >>>>> > http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
> >>>>> Algorithm="
> >>>>> > http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
> >>>>> > URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
> >>>>> > http://www.w3.org/2001/10/xml-exc-c14n#
> >>>>> "/></ds:Transforms><ds:DigestMethod
> >>>>> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
> >>>>>
> "/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
> >>>>> >
> Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
> >>>>> > xmlns:wsse="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >>>>> "><wsse:Reference
> >>>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
> >>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> >>>>>
> "/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
> >>>>> > xmlns="http://xmlsoap.org/Ping
> >>>>> >
> >>>>>
> "><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
> >>>>> >
> >>>>> > 4) Finally, the Metro service response which is a SOAP fault (HTTP
> >>>>> status
> >>>>> > code 500):
> >>>>> >
> >>>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
> >>>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >>>>> "
> >>>>> > xmlns:wsu="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> >>>>> "
> >>>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action
> >>>>> xmlns="
> >>>>> > http://www.w3.org/2005/08/addressing">
> >>>>> > http://www.w3.org/2005/08/addressing/fault</Action><MessageID
> >>>>> xmlns="
> >>>>> > http://www.w3.org/2005/08/addressing
> >>>>> ">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing
> >>>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
> >>>>> > xmlns="http://www.w3.org/2005/08/addressing">
> >>>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
> >>>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
> >>>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
> >>>>> > xmlns:ns13="http://schemas.xmlsoap.org/soap/envelope/"
> >>>>> >
> >>>>>
> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
> >>>>> > xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/
> >>>>> "><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
> >>>>> > xmlns:wsse="
> >>>>> >
> >>>>>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> >>>>>
> ">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
> >>>>> > xml:lang="en">Invalid Security
> >>>>> > Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
> >>>>> >
> >>>>> > Regards,
> >>>>> > Cyril
> >>>>> >
> >>>>> > On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dms@sosnoski.com
> >
> >>>>> wrote:
> >>>>> >
> >>>>> >> Hi Cyril,
> >>>>> >>
> >>>>> >> I've also experienced problems with Metro rejecting the signature
> >>>>> when
> >>>>> >> using WS-SC. I was using the trunk code, though, so assumed it was
> >>>>> probably
> >>>>> >> a new issue with all the 3.0 changes.
> >>>>> >>
> >>>>> >> Are you getting some messages through successfully before the
> >>>>> failure?
> >>>>> >> I'm asking because you say the "final service call" is where the
> >>>>> problem
> >>>>> >> occurs. The failure I was seeing was on the first message using
> the
> >>>>> SC
> >>>>> >> token.
> >>>>> >>
> >>>>> >> Colm, sorry I never supplied the test case for this to you. I'll
> >>>>> get that
> >>>>> >> in this weekend.
> >>>>> >>
> >>>>> >> - Dennis
> >>>>> >>
> >>>>> >> Dennis M. Sosnoski
> >>>>> >> Java Web Services Consulting <
> http://www.sosnoski.com/consult.html>
> >>>>> >> CXF and Web Services Security Training <http://www.sosnoski.com/
> >>>>> >> training.html>
> >>>>> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
> >>>>> >>
> >>>>> >>
> >>>>> >> On 12/21/2013 12:54 PM, Cyril wrote:
> >>>>> >>
> >>>>> >>> Hello,
> >>>>> >>> I have attached again the CXF client log (cxf_client.log.txt).
> Did
> >>>>> you
> >>>>> >>> get jaxws-sc.wsdl and client-cxf.xml?
> >>>>> >>> Thank you for your help.
> >>>>> >>>
> >>>>> >>> Regards,
> >>>>> >>> Cyril
> >>>>> >>>
> >>>>> >>>
> >>>>> >>>
> >>>>> >>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
> >>>>> >>> coheigea@apache.org <ma...@apache.org>> wrote:
> >>>>> >>>
> >>>>> >>> Hi Cyril,
> >>>>> >>>
> >>>>> >>> It appears you didn't attach the logs, could you resend them
> >>>>> >>> please + I
> >>>>> >>> will take a look? The FINE error logs you posted in the
> message
> >>>>> >>> are a red
> >>>>> >>> herring, this just means that CXF did not explicitly mark
> >>>>> certain
> >>>>> >>> policies
> >>>>> >>> are being asserted.
> >>>>> >>>
> >>>>> >>> Colm.
> >>>>> >>>
> >>>>> >>>
> >>>>> >>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
> >>>>> >>> <ma...@gmail.com>> wrote:
> >>>>> >>>
> >>>>> >>> > Hello,
> >>>>> >>> > I am trying to have a WS-SecureConversation between a CXF
> >>>>> client
> >>>>> >>> - version
> >>>>> >>> > 2.7.6 - talking to a Metro service with
> WS-SecureConversation
> >>>>> >>> (over SSL
> >>>>> >>> > TransportBinding). When CXF makes the final service call
> >>>>> with the
> >>>>> >>> > SecurityContextToken in the security header, the service
> >>>>> replies
> >>>>> >>> a SOAP
> >>>>> >>> > fault "Invalid Security Header". The service logs say the
> >>>>> Signature
> >>>>> >>> > Verification for Signature with ID SIG-4 failed. I am
> trying
> >>>>> to
> >>>>> >>> investigate
> >>>>> >>> > more on the service side what is wrong with the signature.
> >>>>> >>> However, I
> >>>>> >>> > noticed the following exceptions in CXF in FINE log level:
> >>>>> >>> >
> >>>>> >>> > Dec 19, 2013 6:37:08 PM
> >>>>> >>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor
> >>>>> handle
> >>>>> >>> > FINE: An exception was thrown when verifying that the
> >>>>> effective
> >>>>> >>> policy for
> >>>>> >>> > this request was satisfied. However, this exception will
> not
> >>>>> >>> result in a
> >>>>> >>> > fault. The exception raised is:
> >>>>> >>> org.apache.cxf.ws.policy.PolicyException:
> >>>>> >>> > These policy alternatives can not be satisfied:
> >>>>> >>> >
> >>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>>>> >>> 200702}SignedParts
> >>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>>>> >>> 200702%7DSignedParts>
> >>>>> >>> >
> >>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>>>> >>> 200702}EncryptedParts
> >>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>>>> >>> 200702%7DEncryptedParts>
> >>>>> >>> >
> >>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>>>> >>> 200702}TransportToken
> >>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>>>> >>> 200702%7DTransportToken>
> >>>>> >>> > {
> >>>>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
> >>>>> >>> <
> >>>>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
> >>>>> >>>
> >>>>> >>> >
> >>>>> >>> > Could this be an issue? Better ideas?
> >>>>> >>> >
> >>>>> >>> > I have attached the service WSDL, and the CXF client
> (Spring)
> >>>>> >>> > configuration and debug logs with the requests/responses.
> >>>>> >>> >
> >>>>> >>> > Thanks for any help.
> >>>>> >>> >
> >>>>> >>> > Regards,
> >>>>> >>> > Cyril
> >>>>> >>> >
> >>>>> >>>
> >>>>> >>>
> >>>>> >>>
> >>>>> >>> --
> >>>>> >>> 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: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Cyril <co...@gmail.com>.
Hello Colm,
please find the test case in the zip uploaded here (file size was rejected
by the mail server):
https://drive.google.com/file/d/0Bx-J-1KEN3jNLWcwVXQ5c3daaGM/edit?usp=sharing
Filename: cxf-client-metro-wssc-interop-test.zip
It is a maven project with a JUnit test case that launches the Metro
service in an embedded Jetty, then runs the CXF client against it. Make
sure the port 8443 is available locally, or change the port in file
src/test/resources/cxf-client.xml (jaxws:client element) and class
simple.client.PingServiceClientTest. If this is not what you expect, please
tell me, as I am not used to create such test cases.
Thanks for reviewing, and sorry for my late reply.
Regards,
Cyril
On Thu, Jan 9, 2014 at 2:48 PM, Colm O hEigeartaigh <co...@apache.org>wrote:
>
> Hi Cyril,
>
> Could you create a test-case that reproduces the problem + I will take a
> look?
>
> Colm.
>
>
> On Tue, Jan 7, 2014 at 3:28 PM, Cyril <co...@gmail.com> wrote:
>
>> Hello,
>> I tried with Basic128 to no avail. Please find the client/server logs in
>> attachment. I have improved the Metro server logs a bit. In particular, I
>> enabled HTTP message dumping there as well to make it easier to correlate
>> client logs with server logs. Besides, you mentioned the fact that the
>> client and service might be deriving keys differently. Yet, I have no
>> <RequireDerivedKeys> assertion in the WSDL. Should there be some key
>> derivation process happening anyway? I looked for derivation-related stuff
>> in the logs and did not find any. But maybe logs are not detailed enough.
>>
>> Thanks for your help.
>>
>> Regards,
>> Cyril
>>
>>
>> On Tue, Jan 7, 2014 at 10:58 AM, Colm O hEigeartaigh <coheigea@apache.org
>> > wrote:
>>
>>>
>>> Ok thanks. Could you try changing the two "Basic256" policies in the
>>> WSDL to "Basic128" + try again to see if it works?
>>>
>>> Colm.
>>>
>>>
>>> On Mon, Jan 6, 2014 at 5:09 PM, Cyril <co...@gmail.com> wrote:
>>>
>>>> Hello,
>>>> I've tried again, with CXF 2.7.8 this time. Please find the logs in
>>>> attachment (zip). The zip contains:
>>>> - The debug logging on the Metro service side (any log from classes in
>>>> packages com.sun.xml.ws.*): metro_wsp_requested by_cxf_wsc.log
>>>> - The corresponding CXF client debug logs: cxf_client.log.
>>>>
>>>> Regards,
>>>> Cyril
>>>>
>>>>
>>>>
>>>> On Fri, Jan 3, 2014 at 12:50 PM, Colm O hEigeartaigh <
>>>> coheigea@apache.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Could you try with CXF 2.7.8 to see if it works? Could you also send
>>>>> debug
>>>>> logging of the service side? It looks like the problem might be that
>>>>> the
>>>>> client + service might be deriving the secret keys in different ways. I
>>>>> fixed some issues on trunk relating to this, but I'm not sure if there
>>>>> were
>>>>> any fixes in 2.7.x or not.
>>>>>
>>>>> Colm.
>>>>>
>>>>>
>>>>> On Thu, Dec 26, 2013 at 1:08 PM, Cyril <co...@gmail.com> wrote:
>>>>>
>>>>> > Hi Dennis,
>>>>> >
>>>>> > Yes, the issue occurs only when calling the service after the
>>>>> security
>>>>> > context token has been successfully obtained.
>>>>> >
>>>>> > 1) If you look for "Outbound Message" from the beginning of the CXF
>>>>> client
>>>>> > log attached, you'll find the first client request which is the
>>>>> RST/SCT
>>>>> > (ID: 1):
>>>>> >
>>>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>>>>> "><soap:Header><Action
>>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT
>>>>> </Action><MessageID
>>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
>>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>>>>> > http://www.w3.org/2005/08/addressing"><Address>
>>>>> > http://www.w3.org/2005/08/addressing/anonymous
>>>>> </Address></ReplyTo><wsse:Security
>>>>> > xmlns:wsse="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>>> "
>>>>> > xmlns:wsu="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> "
>>>>> > soap:mustUnderstand="true"><wsu:Timestamp
>>>>> >
>>>>> wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
>>>>> >
>>>>> wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
>>>>> > Type="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
>>>>> ">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
>>>>> > xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust
>>>>> "><wst:RequestType>
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
>>>>> </wst:RequestType><wsp:AppliesTo
>>>>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
>>>>> > xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
>>>>> > https://localhost:8443/jaxws-sc/simple
>>>>> </wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
>>>>> > xmlns:wsu="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> >
>>>>> "><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>>> </wst:TokenType><wst:Entropy><wst:BinarySecret
>>>>> > Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>>>>> >
>>>>> ">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>>>>> >
>>>>> </wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
>>>>> >
>>>>> > 2) Then look for "Inbound Message" : the Metro service response,
>>>>> which is
>>>>> > the RSTR/SCT (HTTP status code 200). So far so good:
>>>>> >
>>>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>>>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
>>>>> > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>>>>> > xmlns:wsse="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>>> "
>>>>> > xmlns:wsu="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> "
>>>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action
>>>>> xmlns="
>>>>> > http://www.w3.org/2005/08/addressing">
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT
>>>>> </Action><MessageID
>>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>>> ">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
>>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
>>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>>>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
>>>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>>>>> > xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/"
>>>>> >
>>>>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
>>>>> > xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:ns6="
>>>>> > http://www.w3.org/2005/08/addressing" xmlns:ns7="
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
>>>>> > http://schemas.xmlsoap.org/ws/2006/02/addressingidentity"
>>>>> xmlns:ns9="
>>>>> > http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
>>>>> > http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
>>>>> > http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>>> </ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
>>>>> >
>>>>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
>>>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>>> "/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
>>>>> > URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>>> >
>>>>> "/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>>>>> </ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
>>>>> > ns5:Type="BinarySecret"><ns5:BinarySecret Type="
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>>>>> >
>>>>> ">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
>>>>> >
>>>>> > 3) Then the client request with the SCT to the application (ID: 2):
>>>>> >
>>>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>>>>> "><soap:Header><Action
>>>>> > xmlns="http://www.w3.org/2005/08/addressing">http://xmlsoap.org/Ping
>>>>> </Action><MessageID
>>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
>>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>>>>> > http://www.w3.org/2005/08/addressing"><Address>
>>>>> > http://www.w3.org/2005/08/addressing/anonymous
>>>>> </Address></ReplyTo><wsse:Security
>>>>> > xmlns:wsse="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>>> "
>>>>> > xmlns:wsu="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> "
>>>>> > soap:mustUnderstand="true"><wsu:Timestamp
>>>>> >
>>>>> wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
>>>>> > xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> "
>>>>> >
>>>>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
>>>>> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>>>> > Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
>>>>> > http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
>>>>> Algorithm="
>>>>> > http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
>>>>> > URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
>>>>> > http://www.w3.org/2001/10/xml-exc-c14n#
>>>>> "/></ds:Transforms><ds:DigestMethod
>>>>> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
>>>>> "/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
>>>>> > Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
>>>>> > xmlns:wsse="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>>> "><wsse:Reference
>>>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>>> "/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
>>>>> > xmlns="http://xmlsoap.org/Ping
>>>>> >
>>>>> "><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
>>>>> >
>>>>> > 4) Finally, the Metro service response which is a SOAP fault (HTTP
>>>>> status
>>>>> > code 500):
>>>>> >
>>>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>>>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>>> "
>>>>> > xmlns:wsu="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> "
>>>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action
>>>>> xmlns="
>>>>> > http://www.w3.org/2005/08/addressing">
>>>>> > http://www.w3.org/2005/08/addressing/fault</Action><MessageID
>>>>> xmlns="
>>>>> > http://www.w3.org/2005/08/addressing
>>>>> ">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
>>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
>>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>>>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
>>>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>>>>> > xmlns:ns13="http://schemas.xmlsoap.org/soap/envelope/"
>>>>> >
>>>>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
>>>>> > xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/
>>>>> "><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
>>>>> > xmlns:wsse="
>>>>> >
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>>> ">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
>>>>> > xml:lang="en">Invalid Security
>>>>> > Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
>>>>> >
>>>>> > Regards,
>>>>> > Cyril
>>>>> >
>>>>> > On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dm...@sosnoski.com>
>>>>> wrote:
>>>>> >
>>>>> >> Hi Cyril,
>>>>> >>
>>>>> >> I've also experienced problems with Metro rejecting the signature
>>>>> when
>>>>> >> using WS-SC. I was using the trunk code, though, so assumed it was
>>>>> probably
>>>>> >> a new issue with all the 3.0 changes.
>>>>> >>
>>>>> >> Are you getting some messages through successfully before the
>>>>> failure?
>>>>> >> I'm asking because you say the "final service call" is where the
>>>>> problem
>>>>> >> occurs. The failure I was seeing was on the first message using the
>>>>> SC
>>>>> >> token.
>>>>> >>
>>>>> >> Colm, sorry I never supplied the test case for this to you. I'll
>>>>> get that
>>>>> >> in this weekend.
>>>>> >>
>>>>> >> - Dennis
>>>>> >>
>>>>> >> Dennis M. Sosnoski
>>>>> >> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>>>>> >> CXF and Web Services Security Training <http://www.sosnoski.com/
>>>>> >> training.html>
>>>>> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>>>>> >>
>>>>> >>
>>>>> >> On 12/21/2013 12:54 PM, Cyril wrote:
>>>>> >>
>>>>> >>> Hello,
>>>>> >>> I have attached again the CXF client log (cxf_client.log.txt). Did
>>>>> you
>>>>> >>> get jaxws-sc.wsdl and client-cxf.xml?
>>>>> >>> Thank you for your help.
>>>>> >>>
>>>>> >>> Regards,
>>>>> >>> Cyril
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
>>>>> >>> coheigea@apache.org <ma...@apache.org>> wrote:
>>>>> >>>
>>>>> >>> Hi Cyril,
>>>>> >>>
>>>>> >>> It appears you didn't attach the logs, could you resend them
>>>>> >>> please + I
>>>>> >>> will take a look? The FINE error logs you posted in the message
>>>>> >>> are a red
>>>>> >>> herring, this just means that CXF did not explicitly mark
>>>>> certain
>>>>> >>> policies
>>>>> >>> are being asserted.
>>>>> >>>
>>>>> >>> Colm.
>>>>> >>>
>>>>> >>>
>>>>> >>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
>>>>> >>> <ma...@gmail.com>> wrote:
>>>>> >>>
>>>>> >>> > Hello,
>>>>> >>> > I am trying to have a WS-SecureConversation between a CXF
>>>>> client
>>>>> >>> - version
>>>>> >>> > 2.7.6 - talking to a Metro service with WS-SecureConversation
>>>>> >>> (over SSL
>>>>> >>> > TransportBinding). When CXF makes the final service call
>>>>> with the
>>>>> >>> > SecurityContextToken in the security header, the service
>>>>> replies
>>>>> >>> a SOAP
>>>>> >>> > fault "Invalid Security Header". The service logs say the
>>>>> Signature
>>>>> >>> > Verification for Signature with ID SIG-4 failed. I am trying
>>>>> to
>>>>> >>> investigate
>>>>> >>> > more on the service side what is wrong with the signature.
>>>>> >>> However, I
>>>>> >>> > noticed the following exceptions in CXF in FINE log level:
>>>>> >>> >
>>>>> >>> > Dec 19, 2013 6:37:08 PM
>>>>> >>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor
>>>>> handle
>>>>> >>> > FINE: An exception was thrown when verifying that the
>>>>> effective
>>>>> >>> policy for
>>>>> >>> > this request was satisfied. However, this exception will not
>>>>> >>> result in a
>>>>> >>> > fault. The exception raised is:
>>>>> >>> org.apache.cxf.ws.policy.PolicyException:
>>>>> >>> > These policy alternatives can not be satisfied:
>>>>> >>> >
>>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>>> >>> 200702}SignedParts
>>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>>> >>> 200702%7DSignedParts>
>>>>> >>> >
>>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>>> >>> 200702}EncryptedParts
>>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>>> >>> 200702%7DEncryptedParts>
>>>>> >>> >
>>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>>> >>> 200702}TransportToken
>>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>>> >>> 200702%7DTransportToken>
>>>>> >>> > {
>>>>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
>>>>> >>> <
>>>>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
>>>>> >>>
>>>>> >>> >
>>>>> >>> > Could this be an issue? Better ideas?
>>>>> >>> >
>>>>> >>> > I have attached the service WSDL, and the CXF client (Spring)
>>>>> >>> > configuration and debug logs with the requests/responses.
>>>>> >>> >
>>>>> >>> > Thanks for any help.
>>>>> >>> >
>>>>> >>> > Regards,
>>>>> >>> > Cyril
>>>>> >>> >
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> 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: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Cyril,
Could you create a test-case that reproduces the problem + I will take a
look?
Colm.
On Tue, Jan 7, 2014 at 3:28 PM, Cyril <co...@gmail.com> wrote:
> Hello,
> I tried with Basic128 to no avail. Please find the client/server logs in
> attachment. I have improved the Metro server logs a bit. In particular, I
> enabled HTTP message dumping there as well to make it easier to correlate
> client logs with server logs. Besides, you mentioned the fact that the
> client and service might be deriving keys differently. Yet, I have no
> <RequireDerivedKeys> assertion in the WSDL. Should there be some key
> derivation process happening anyway? I looked for derivation-related stuff
> in the logs and did not find any. But maybe logs are not detailed enough.
>
> Thanks for your help.
>
> Regards,
> Cyril
>
>
> On Tue, Jan 7, 2014 at 10:58 AM, Colm O hEigeartaigh <co...@apache.org>wrote:
>
>>
>> Ok thanks. Could you try changing the two "Basic256" policies in the WSDL
>> to "Basic128" + try again to see if it works?
>>
>> Colm.
>>
>>
>> On Mon, Jan 6, 2014 at 5:09 PM, Cyril <co...@gmail.com> wrote:
>>
>>> Hello,
>>> I've tried again, with CXF 2.7.8 this time. Please find the logs in
>>> attachment (zip). The zip contains:
>>> - The debug logging on the Metro service side (any log from classes in
>>> packages com.sun.xml.ws.*): metro_wsp_requested by_cxf_wsc.log
>>> - The corresponding CXF client debug logs: cxf_client.log.
>>>
>>> Regards,
>>> Cyril
>>>
>>>
>>>
>>> On Fri, Jan 3, 2014 at 12:50 PM, Colm O hEigeartaigh <
>>> coheigea@apache.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Could you try with CXF 2.7.8 to see if it works? Could you also send
>>>> debug
>>>> logging of the service side? It looks like the problem might be that the
>>>> client + service might be deriving the secret keys in different ways. I
>>>> fixed some issues on trunk relating to this, but I'm not sure if there
>>>> were
>>>> any fixes in 2.7.x or not.
>>>>
>>>> Colm.
>>>>
>>>>
>>>> On Thu, Dec 26, 2013 at 1:08 PM, Cyril <co...@gmail.com> wrote:
>>>>
>>>> > Hi Dennis,
>>>> >
>>>> > Yes, the issue occurs only when calling the service after the security
>>>> > context token has been successfully obtained.
>>>> >
>>>> > 1) If you look for "Outbound Message" from the beginning of the CXF
>>>> client
>>>> > log attached, you'll find the first client request which is the
>>>> RST/SCT
>>>> > (ID: 1):
>>>> >
>>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>>>> "><soap:Header><Action
>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT
>>>> </Action><MessageID
>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>>>> > http://www.w3.org/2005/08/addressing"><Address>
>>>> > http://www.w3.org/2005/08/addressing/anonymous
>>>> </Address></ReplyTo><wsse:Security
>>>> > xmlns:wsse="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>> "
>>>> > xmlns:wsu="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> "
>>>> > soap:mustUnderstand="true"><wsu:Timestamp
>>>> >
>>>> wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
>>>> >
>>>> wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
>>>> > Type="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
>>>> ">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
>>>> > xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust
>>>> "><wst:RequestType>
>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
>>>> </wst:RequestType><wsp:AppliesTo
>>>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
>>>> > xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
>>>> > https://localhost:8443/jaxws-sc/simple
>>>> </wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
>>>> > xmlns:wsu="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> >
>>>> "><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>> </wst:TokenType><wst:Entropy><wst:BinarySecret
>>>> > Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>>>> >
>>>> ">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>>>> >
>>>> </wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
>>>> >
>>>> > 2) Then look for "Inbound Message" : the Metro service response,
>>>> which is
>>>> > the RSTR/SCT (HTTP status code 200). So far so good:
>>>> >
>>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
>>>> > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>>>> > xmlns:wsse="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>> "
>>>> > xmlns:wsu="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> "
>>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
>>>> > http://www.w3.org/2005/08/addressing">
>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT
>>>> </Action><MessageID
>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>> ">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
>>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>>>> > xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/"
>>>> >
>>>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
>>>> > xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:ns6="
>>>> > http://www.w3.org/2005/08/addressing" xmlns:ns7="
>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
>>>> > http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:ns9="
>>>> > http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
>>>> > http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
>>>> > http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>> </ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
>>>> >
>>>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
>>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>> "/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
>>>> > URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>> >
>>>> "/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>>>> </ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
>>>> > ns5:Type="BinarySecret"><ns5:BinarySecret Type="
>>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>>>> >
>>>> ">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
>>>> >
>>>> > 3) Then the client request with the SCT to the application (ID: 2):
>>>> >
>>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>>>> "><soap:Header><Action
>>>> > xmlns="http://www.w3.org/2005/08/addressing">http://xmlsoap.org/Ping
>>>> </Action><MessageID
>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>>>> > http://www.w3.org/2005/08/addressing"><Address>
>>>> > http://www.w3.org/2005/08/addressing/anonymous
>>>> </Address></ReplyTo><wsse:Security
>>>> > xmlns:wsse="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>> "
>>>> > xmlns:wsu="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> "
>>>> > soap:mustUnderstand="true"><wsu:Timestamp
>>>> >
>>>> wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
>>>> > xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> "
>>>> >
>>>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
>>>> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>>> > Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
>>>> > http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
>>>> Algorithm="
>>>> > http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
>>>> > URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
>>>> > http://www.w3.org/2001/10/xml-exc-c14n#
>>>> "/></ds:Transforms><ds:DigestMethod
>>>> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
>>>> "/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
>>>> > Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
>>>> > xmlns:wsse="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>> "><wsse:Reference
>>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>>> "/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
>>>> > xmlns="http://xmlsoap.org/Ping
>>>> >
>>>> "><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
>>>> >
>>>> > 4) Finally, the Metro service response which is a SOAP fault (HTTP
>>>> status
>>>> > code 500):
>>>> >
>>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>> "
>>>> > xmlns:wsu="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> "
>>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
>>>> > http://www.w3.org/2005/08/addressing">
>>>> > http://www.w3.org/2005/08/addressing/fault</Action><MessageID xmlns="
>>>> > http://www.w3.org/2005/08/addressing
>>>> ">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
>>>> > xmlns="http://www.w3.org/2005/08/addressing
>>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
>>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
>>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>>>> > xmlns:ns13="http://schemas.xmlsoap.org/soap/envelope/"
>>>> >
>>>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
>>>> > xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/
>>>> "><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
>>>> > xmlns:wsse="
>>>> >
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>>> ">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
>>>> > xml:lang="en">Invalid Security
>>>> > Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
>>>> >
>>>> > Regards,
>>>> > Cyril
>>>> >
>>>> > On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dm...@sosnoski.com>
>>>> wrote:
>>>> >
>>>> >> Hi Cyril,
>>>> >>
>>>> >> I've also experienced problems with Metro rejecting the signature
>>>> when
>>>> >> using WS-SC. I was using the trunk code, though, so assumed it was
>>>> probably
>>>> >> a new issue with all the 3.0 changes.
>>>> >>
>>>> >> Are you getting some messages through successfully before the
>>>> failure?
>>>> >> I'm asking because you say the "final service call" is where the
>>>> problem
>>>> >> occurs. The failure I was seeing was on the first message using the
>>>> SC
>>>> >> token.
>>>> >>
>>>> >> Colm, sorry I never supplied the test case for this to you. I'll get
>>>> that
>>>> >> in this weekend.
>>>> >>
>>>> >> - Dennis
>>>> >>
>>>> >> Dennis M. Sosnoski
>>>> >> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>>>> >> CXF and Web Services Security Training <http://www.sosnoski.com/
>>>> >> training.html>
>>>> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>>>> >>
>>>> >>
>>>> >> On 12/21/2013 12:54 PM, Cyril wrote:
>>>> >>
>>>> >>> Hello,
>>>> >>> I have attached again the CXF client log (cxf_client.log.txt). Did
>>>> you
>>>> >>> get jaxws-sc.wsdl and client-cxf.xml?
>>>> >>> Thank you for your help.
>>>> >>>
>>>> >>> Regards,
>>>> >>> Cyril
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
>>>> >>> coheigea@apache.org <ma...@apache.org>> wrote:
>>>> >>>
>>>> >>> Hi Cyril,
>>>> >>>
>>>> >>> It appears you didn't attach the logs, could you resend them
>>>> >>> please + I
>>>> >>> will take a look? The FINE error logs you posted in the message
>>>> >>> are a red
>>>> >>> herring, this just means that CXF did not explicitly mark
>>>> certain
>>>> >>> policies
>>>> >>> are being asserted.
>>>> >>>
>>>> >>> Colm.
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
>>>> >>> <ma...@gmail.com>> wrote:
>>>> >>>
>>>> >>> > Hello,
>>>> >>> > I am trying to have a WS-SecureConversation between a CXF
>>>> client
>>>> >>> - version
>>>> >>> > 2.7.6 - talking to a Metro service with WS-SecureConversation
>>>> >>> (over SSL
>>>> >>> > TransportBinding). When CXF makes the final service call with
>>>> the
>>>> >>> > SecurityContextToken in the security header, the service
>>>> replies
>>>> >>> a SOAP
>>>> >>> > fault "Invalid Security Header". The service logs say the
>>>> Signature
>>>> >>> > Verification for Signature with ID SIG-4 failed. I am trying
>>>> to
>>>> >>> investigate
>>>> >>> > more on the service side what is wrong with the signature.
>>>> >>> However, I
>>>> >>> > noticed the following exceptions in CXF in FINE log level:
>>>> >>> >
>>>> >>> > Dec 19, 2013 6:37:08 PM
>>>> >>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor
>>>> handle
>>>> >>> > FINE: An exception was thrown when verifying that the
>>>> effective
>>>> >>> policy for
>>>> >>> > this request was satisfied. However, this exception will not
>>>> >>> result in a
>>>> >>> > fault. The exception raised is:
>>>> >>> org.apache.cxf.ws.policy.PolicyException:
>>>> >>> > These policy alternatives can not be satisfied:
>>>> >>> >
>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>> >>> 200702}SignedParts
>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>> >>> 200702%7DSignedParts>
>>>> >>> >
>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>> >>> 200702}EncryptedParts
>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>> >>> 200702%7DEncryptedParts>
>>>> >>> >
>>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>> >>> 200702}TransportToken
>>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>>> >>> 200702%7DTransportToken>
>>>> >>> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
>>>> >>> <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10
>>>> >
>>>> >>>
>>>> >>> >
>>>> >>> > Could this be an issue? Better ideas?
>>>> >>> >
>>>> >>> > I have attached the service WSDL, and the CXF client (Spring)
>>>> >>> > configuration and debug logs with the requests/responses.
>>>> >>> >
>>>> >>> > Thanks for any help.
>>>> >>> >
>>>> >>> > Regards,
>>>> >>> > Cyril
>>>> >>> >
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> 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: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Cyril <co...@gmail.com>.
Hello,
I tried with Basic128 to no avail. Please find the client/server logs in
attachment. I have improved the Metro server logs a bit. In particular, I
enabled HTTP message dumping there as well to make it easier to correlate
client logs with server logs. Besides, you mentioned the fact that the
client and service might be deriving keys differently. Yet, I have no
<RequireDerivedKeys> assertion in the WSDL. Should there be some key
derivation process happening anyway? I looked for derivation-related stuff
in the logs and did not find any. But maybe logs are not detailed enough.
Thanks for your help.
Regards,
Cyril
On Tue, Jan 7, 2014 at 10:58 AM, Colm O hEigeartaigh <co...@apache.org>wrote:
>
> Ok thanks. Could you try changing the two "Basic256" policies in the WSDL
> to "Basic128" + try again to see if it works?
>
> Colm.
>
>
> On Mon, Jan 6, 2014 at 5:09 PM, Cyril <co...@gmail.com> wrote:
>
>> Hello,
>> I've tried again, with CXF 2.7.8 this time. Please find the logs in
>> attachment (zip). The zip contains:
>> - The debug logging on the Metro service side (any log from classes in
>> packages com.sun.xml.ws.*): metro_wsp_requested by_cxf_wsc.log
>> - The corresponding CXF client debug logs: cxf_client.log.
>>
>> Regards,
>> Cyril
>>
>>
>>
>> On Fri, Jan 3, 2014 at 12:50 PM, Colm O hEigeartaigh <coheigea@apache.org
>> > wrote:
>>
>>> Hi,
>>>
>>> Could you try with CXF 2.7.8 to see if it works? Could you also send
>>> debug
>>> logging of the service side? It looks like the problem might be that the
>>> client + service might be deriving the secret keys in different ways. I
>>> fixed some issues on trunk relating to this, but I'm not sure if there
>>> were
>>> any fixes in 2.7.x or not.
>>>
>>> Colm.
>>>
>>>
>>> On Thu, Dec 26, 2013 at 1:08 PM, Cyril <co...@gmail.com> wrote:
>>>
>>> > Hi Dennis,
>>> >
>>> > Yes, the issue occurs only when calling the service after the security
>>> > context token has been successfully obtained.
>>> >
>>> > 1) If you look for "Outbound Message" from the beginning of the CXF
>>> client
>>> > log attached, you'll find the first client request which is the RST/SCT
>>> > (ID: 1):
>>> >
>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>>> "><soap:Header><Action
>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</Action><MessageID
>>> > xmlns="http://www.w3.org/2005/08/addressing
>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>>> > http://www.w3.org/2005/08/addressing"><Address>
>>> > http://www.w3.org/2005/08/addressing/anonymous
>>> </Address></ReplyTo><wsse:Security
>>> > xmlns:wsse="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> "
>>> > xmlns:wsu="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> "
>>> > soap:mustUnderstand="true"><wsu:Timestamp
>>> >
>>> wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
>>> >
>>> wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
>>> > Type="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
>>> ">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
>>> > xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust
>>> "><wst:RequestType>
>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
>>> </wst:RequestType><wsp:AppliesTo
>>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
>>> > xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
>>> > https://localhost:8443/jaxws-sc/simple
>>> </wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
>>> > xmlns:wsu="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> >
>>> "><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>> </wst:TokenType><wst:Entropy><wst:BinarySecret
>>> > Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>>> >
>>> ">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>>> >
>>> </wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
>>> >
>>> > 2) Then look for "Inbound Message" : the Metro service response, which
>>> is
>>> > the RSTR/SCT (HTTP status code 200). So far so good:
>>> >
>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
>>> > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>>> > xmlns:wsse="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> "
>>> > xmlns:wsu="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> "
>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
>>> > http://www.w3.org/2005/08/addressing">
>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT
>>> </Action><MessageID
>>> > xmlns="http://www.w3.org/2005/08/addressing
>>> ">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
>>> > xmlns="http://www.w3.org/2005/08/addressing
>>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>>> > xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/"
>>> >
>>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
>>> > xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:ns6="
>>> > http://www.w3.org/2005/08/addressing" xmlns:ns7="
>>> > http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
>>> > http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:ns9="
>>> > http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
>>> > http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
>>> > http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>> </ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
>>> >
>>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>> "/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
>>> > URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>> >
>>> "/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>>> </ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
>>> > ns5:Type="BinarySecret"><ns5:BinarySecret Type="
>>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>>> >
>>> ">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
>>> >
>>> > 3) Then the client request with the SCT to the application (ID: 2):
>>> >
>>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>>> "><soap:Header><Action
>>> > xmlns="http://www.w3.org/2005/08/addressing">http://xmlsoap.org/Ping
>>> </Action><MessageID
>>> > xmlns="http://www.w3.org/2005/08/addressing
>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>>> > http://www.w3.org/2005/08/addressing"><Address>
>>> > http://www.w3.org/2005/08/addressing/anonymous
>>> </Address></ReplyTo><wsse:Security
>>> > xmlns:wsse="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> "
>>> > xmlns:wsu="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> "
>>> > soap:mustUnderstand="true"><wsu:Timestamp
>>> >
>>> wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
>>> > xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> "
>>> >
>>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
>>> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>> > Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
>>> > http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
>>> Algorithm="
>>> > http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
>>> > URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
>>> > http://www.w3.org/2001/10/xml-exc-c14n#
>>> "/></ds:Transforms><ds:DigestMethod
>>> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
>>> "/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
>>> > Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
>>> > xmlns:wsse="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> "><wsse:Reference
>>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>>> "/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
>>> > xmlns="http://xmlsoap.org/Ping
>>> >
>>> "><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
>>> >
>>> > 4) Finally, the Metro service response which is a SOAP fault (HTTP
>>> status
>>> > code 500):
>>> >
>>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> "
>>> > xmlns:wsu="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> "
>>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
>>> > http://www.w3.org/2005/08/addressing">
>>> > http://www.w3.org/2005/08/addressing/fault</Action><MessageID xmlns="
>>> > http://www.w3.org/2005/08/addressing
>>> ">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
>>> > xmlns="http://www.w3.org/2005/08/addressing
>>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
>>> > xmlns="http://www.w3.org/2005/08/addressing">
>>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
>>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>>> > xmlns:ns13="http://schemas.xmlsoap.org/soap/envelope/"
>>> >
>>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
>>> > xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/
>>> "><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
>>> > xmlns:wsse="
>>> >
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>>> ">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
>>> > xml:lang="en">Invalid Security
>>> > Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
>>> >
>>> > Regards,
>>> > Cyril
>>> >
>>> > On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dm...@sosnoski.com>
>>> wrote:
>>> >
>>> >> Hi Cyril,
>>> >>
>>> >> I've also experienced problems with Metro rejecting the signature when
>>> >> using WS-SC. I was using the trunk code, though, so assumed it was
>>> probably
>>> >> a new issue with all the 3.0 changes.
>>> >>
>>> >> Are you getting some messages through successfully before the failure?
>>> >> I'm asking because you say the "final service call" is where the
>>> problem
>>> >> occurs. The failure I was seeing was on the first message using the SC
>>> >> token.
>>> >>
>>> >> Colm, sorry I never supplied the test case for this to you. I'll get
>>> that
>>> >> in this weekend.
>>> >>
>>> >> - Dennis
>>> >>
>>> >> Dennis M. Sosnoski
>>> >> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>>> >> CXF and Web Services Security Training <http://www.sosnoski.com/
>>> >> training.html>
>>> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>>> >>
>>> >>
>>> >> On 12/21/2013 12:54 PM, Cyril wrote:
>>> >>
>>> >>> Hello,
>>> >>> I have attached again the CXF client log (cxf_client.log.txt). Did
>>> you
>>> >>> get jaxws-sc.wsdl and client-cxf.xml?
>>> >>> Thank you for your help.
>>> >>>
>>> >>> Regards,
>>> >>> Cyril
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
>>> >>> coheigea@apache.org <ma...@apache.org>> wrote:
>>> >>>
>>> >>> Hi Cyril,
>>> >>>
>>> >>> It appears you didn't attach the logs, could you resend them
>>> >>> please + I
>>> >>> will take a look? The FINE error logs you posted in the message
>>> >>> are a red
>>> >>> herring, this just means that CXF did not explicitly mark certain
>>> >>> policies
>>> >>> are being asserted.
>>> >>>
>>> >>> Colm.
>>> >>>
>>> >>>
>>> >>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
>>> >>> <ma...@gmail.com>> wrote:
>>> >>>
>>> >>> > Hello,
>>> >>> > I am trying to have a WS-SecureConversation between a CXF
>>> client
>>> >>> - version
>>> >>> > 2.7.6 - talking to a Metro service with WS-SecureConversation
>>> >>> (over SSL
>>> >>> > TransportBinding). When CXF makes the final service call with
>>> the
>>> >>> > SecurityContextToken in the security header, the service
>>> replies
>>> >>> a SOAP
>>> >>> > fault "Invalid Security Header". The service logs say the
>>> Signature
>>> >>> > Verification for Signature with ID SIG-4 failed. I am trying to
>>> >>> investigate
>>> >>> > more on the service side what is wrong with the signature.
>>> >>> However, I
>>> >>> > noticed the following exceptions in CXF in FINE log level:
>>> >>> >
>>> >>> > Dec 19, 2013 6:37:08 PM
>>> >>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor
>>> handle
>>> >>> > FINE: An exception was thrown when verifying that the effective
>>> >>> policy for
>>> >>> > this request was satisfied. However, this exception will not
>>> >>> result in a
>>> >>> > fault. The exception raised is:
>>> >>> org.apache.cxf.ws.policy.PolicyException:
>>> >>> > These policy alternatives can not be satisfied:
>>> >>> >
>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> >>> 200702}SignedParts
>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> >>> 200702%7DSignedParts>
>>> >>> >
>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> >>> 200702}EncryptedParts
>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> >>> 200702%7DEncryptedParts>
>>> >>> >
>>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> >>> 200702}TransportToken
>>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> >>> 200702%7DTransportToken>
>>> >>> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
>>> >>> <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
>>> >>>
>>> >>> >
>>> >>> > Could this be an issue? Better ideas?
>>> >>> >
>>> >>> > I have attached the service WSDL, and the CXF client (Spring)
>>> >>> > configuration and debug logs with the requests/responses.
>>> >>> >
>>> >>> > Thanks for any help.
>>> >>> >
>>> >>> > Regards,
>>> >>> > Cyril
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> 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: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok thanks. Could you try changing the two "Basic256" policies in the WSDL
to "Basic128" + try again to see if it works?
Colm.
On Mon, Jan 6, 2014 at 5:09 PM, Cyril <co...@gmail.com> wrote:
> Hello,
> I've tried again, with CXF 2.7.8 this time. Please find the logs in
> attachment (zip). The zip contains:
> - The debug logging on the Metro service side (any log from classes in
> packages com.sun.xml.ws.*): metro_wsp_requested by_cxf_wsc.log
> - The corresponding CXF client debug logs: cxf_client.log.
>
> Regards,
> Cyril
>
>
>
> On Fri, Jan 3, 2014 at 12:50 PM, Colm O hEigeartaigh <co...@apache.org>wrote:
>
>> Hi,
>>
>> Could you try with CXF 2.7.8 to see if it works? Could you also send debug
>> logging of the service side? It looks like the problem might be that the
>> client + service might be deriving the secret keys in different ways. I
>> fixed some issues on trunk relating to this, but I'm not sure if there
>> were
>> any fixes in 2.7.x or not.
>>
>> Colm.
>>
>>
>> On Thu, Dec 26, 2013 at 1:08 PM, Cyril <co...@gmail.com> wrote:
>>
>> > Hi Dennis,
>> >
>> > Yes, the issue occurs only when calling the service after the security
>> > context token has been successfully obtained.
>> >
>> > 1) If you look for "Outbound Message" from the beginning of the CXF
>> client
>> > log attached, you'll find the first client request which is the RST/SCT
>> > (ID: 1):
>> >
>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>> "><soap:Header><Action
>> > xmlns="http://www.w3.org/2005/08/addressing">
>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</Action><MessageID
>> > xmlns="http://www.w3.org/2005/08/addressing
>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
>> > xmlns="http://www.w3.org/2005/08/addressing">
>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>> > http://www.w3.org/2005/08/addressing"><Address>
>> > http://www.w3.org/2005/08/addressing/anonymous
>> </Address></ReplyTo><wsse:Security
>> > xmlns:wsse="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "
>> > xmlns:wsu="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> > soap:mustUnderstand="true"><wsu:Timestamp
>> >
>> wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
>> >
>> wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
>> > Type="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
>> ">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
>> > xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust
>> "><wst:RequestType>
>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
>> </wst:RequestType><wsp:AppliesTo
>> > xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
>> > xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
>> > https://localhost:8443/jaxws-sc/simple
>> </wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
>> > xmlns:wsu="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> >
>> "><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>> </wst:TokenType><wst:Entropy><wst:BinarySecret
>> > Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>> >
>> ">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>> >
>> </wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
>> >
>> > 2) Then look for "Inbound Message" : the Metro service response, which
>> is
>> > the RSTR/SCT (HTTP status code 200). So far so good:
>> >
>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
>> > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>> > xmlns:wsse="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "
>> > xmlns:wsu="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
>> > http://www.w3.org/2005/08/addressing">
>> > http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</Action><MessageID
>> > xmlns="http://www.w3.org/2005/08/addressing
>> ">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
>> > xmlns="http://www.w3.org/2005/08/addressing
>> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
>> > xmlns="http://www.w3.org/2005/08/addressing">
>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>> > xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/"
>> >
>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
>> > xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:ns6="
>> > http://www.w3.org/2005/08/addressing" xmlns:ns7="
>> > http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
>> > http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:ns9="
>> > http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
>> > http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
>> > http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>> </ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
>> >
>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>> "/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
>> > URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>> >
>> "/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
>> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
>> </ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
>> > ns5:Type="BinarySecret"><ns5:BinarySecret Type="
>> > http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
>> >
>> ">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
>> >
>> > 3) Then the client request with the SCT to the application (ID: 2):
>> >
>> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
>> "><soap:Header><Action
>> > xmlns="http://www.w3.org/2005/08/addressing">http://xmlsoap.org/Ping
>> </Action><MessageID
>> > xmlns="http://www.w3.org/2005/08/addressing
>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
>> > xmlns="http://www.w3.org/2005/08/addressing">
>> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
>> > http://www.w3.org/2005/08/addressing"><Address>
>> > http://www.w3.org/2005/08/addressing/anonymous
>> </Address></ReplyTo><wsse:Security
>> > xmlns:wsse="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "
>> > xmlns:wsu="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> > soap:mustUnderstand="true"><wsu:Timestamp
>> >
>> wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
>> > xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> >
>> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
>> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>> > Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
>> > http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
>> Algorithm="
>> > http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
>> > URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
>> > http://www.w3.org/2001/10/xml-exc-c14n#
>> "/></ds:Transforms><ds:DigestMethod
>> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
>> "/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
>> > Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
>> > xmlns:wsse="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "><wsse:Reference
>> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
>> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
>> "/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
>> > xmlns="http://xmlsoap.org/Ping
>> >
>> "><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
>> >
>> > 4) Finally, the Metro service response which is a SOAP fault (HTTP
>> status
>> > code 500):
>> >
>> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
>> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "
>> > xmlns:wsu="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
>> > http://www.w3.org/2005/08/addressing">
>> > http://www.w3.org/2005/08/addressing/fault</Action><MessageID xmlns="
>> > http://www.w3.org/2005/08/addressing
>> ">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
>> > xmlns="http://www.w3.org/2005/08/addressing
>> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
>> > xmlns="http://www.w3.org/2005/08/addressing">
>> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
>> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
>> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
>> > xmlns:ns13="http://schemas.xmlsoap.org/soap/envelope/"
>> >
>> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
>> > xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/
>> "><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
>> > xmlns:wsse="
>> >
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> ">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
>> > xml:lang="en">Invalid Security
>> > Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
>> >
>> > Regards,
>> > Cyril
>> >
>> > On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dm...@sosnoski.com>
>> wrote:
>> >
>> >> Hi Cyril,
>> >>
>> >> I've also experienced problems with Metro rejecting the signature when
>> >> using WS-SC. I was using the trunk code, though, so assumed it was
>> probably
>> >> a new issue with all the 3.0 changes.
>> >>
>> >> Are you getting some messages through successfully before the failure?
>> >> I'm asking because you say the "final service call" is where the
>> problem
>> >> occurs. The failure I was seeing was on the first message using the SC
>> >> token.
>> >>
>> >> Colm, sorry I never supplied the test case for this to you. I'll get
>> that
>> >> in this weekend.
>> >>
>> >> - Dennis
>> >>
>> >> Dennis M. Sosnoski
>> >> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>> >> CXF and Web Services Security Training <http://www.sosnoski.com/
>> >> training.html>
>> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>> >>
>> >>
>> >> On 12/21/2013 12:54 PM, Cyril wrote:
>> >>
>> >>> Hello,
>> >>> I have attached again the CXF client log (cxf_client.log.txt). Did you
>> >>> get jaxws-sc.wsdl and client-cxf.xml?
>> >>> Thank you for your help.
>> >>>
>> >>> Regards,
>> >>> Cyril
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
>> >>> coheigea@apache.org <ma...@apache.org>> wrote:
>> >>>
>> >>> Hi Cyril,
>> >>>
>> >>> It appears you didn't attach the logs, could you resend them
>> >>> please + I
>> >>> will take a look? The FINE error logs you posted in the message
>> >>> are a red
>> >>> herring, this just means that CXF did not explicitly mark certain
>> >>> policies
>> >>> are being asserted.
>> >>>
>> >>> Colm.
>> >>>
>> >>>
>> >>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
>> >>> <ma...@gmail.com>> wrote:
>> >>>
>> >>> > Hello,
>> >>> > I am trying to have a WS-SecureConversation between a CXF client
>> >>> - version
>> >>> > 2.7.6 - talking to a Metro service with WS-SecureConversation
>> >>> (over SSL
>> >>> > TransportBinding). When CXF makes the final service call with
>> the
>> >>> > SecurityContextToken in the security header, the service replies
>> >>> a SOAP
>> >>> > fault "Invalid Security Header". The service logs say the
>> Signature
>> >>> > Verification for Signature with ID SIG-4 failed. I am trying to
>> >>> investigate
>> >>> > more on the service side what is wrong with the signature.
>> >>> However, I
>> >>> > noticed the following exceptions in CXF in FINE log level:
>> >>> >
>> >>> > Dec 19, 2013 6:37:08 PM
>> >>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
>> >>> > FINE: An exception was thrown when verifying that the effective
>> >>> policy for
>> >>> > this request was satisfied. However, this exception will not
>> >>> result in a
>> >>> > fault. The exception raised is:
>> >>> org.apache.cxf.ws.policy.PolicyException:
>> >>> > These policy alternatives can not be satisfied:
>> >>> >
>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> >>> 200702}SignedParts
>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> >>> 200702%7DSignedParts>
>> >>> >
>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> >>> 200702}EncryptedParts
>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> >>> 200702%7DEncryptedParts>
>> >>> >
>> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> >>> 200702}TransportToken
>> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> >>> 200702%7DTransportToken>
>> >>> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
>> >>> <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
>> >>>
>> >>> >
>> >>> > Could this be an issue? Better ideas?
>> >>> >
>> >>> > I have attached the service WSDL, and the CXF client (Spring)
>> >>> > configuration and debug logs with the requests/responses.
>> >>> >
>> >>> > Thanks for any help.
>> >>> >
>> >>> > Regards,
>> >>> > Cyril
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 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: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Cyril <co...@gmail.com>.
Hello,
I've tried again, with CXF 2.7.8 this time. Please find the logs in
attachment (zip). The zip contains:
- The debug logging on the Metro service side (any log from classes in
packages com.sun.xml.ws.*): metro_wsp_requested by_cxf_wsc.log
- The corresponding CXF client debug logs: cxf_client.log.
Regards,
Cyril
On Fri, Jan 3, 2014 at 12:50 PM, Colm O hEigeartaigh <co...@apache.org>wrote:
> Hi,
>
> Could you try with CXF 2.7.8 to see if it works? Could you also send debug
> logging of the service side? It looks like the problem might be that the
> client + service might be deriving the secret keys in different ways. I
> fixed some issues on trunk relating to this, but I'm not sure if there were
> any fixes in 2.7.x or not.
>
> Colm.
>
>
> On Thu, Dec 26, 2013 at 1:08 PM, Cyril <co...@gmail.com> wrote:
>
> > Hi Dennis,
> >
> > Yes, the issue occurs only when calling the service after the security
> > context token has been successfully obtained.
> >
> > 1) If you look for "Outbound Message" from the beginning of the CXF
> client
> > log attached, you'll find the first client request which is the RST/SCT
> > (ID: 1):
> >
> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
> "><soap:Header><Action
> > xmlns="http://www.w3.org/2005/08/addressing">
> > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</Action><MessageID
> > xmlns="http://www.w3.org/2005/08/addressing
> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
> > xmlns="http://www.w3.org/2005/08/addressing">
> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
> > http://www.w3.org/2005/08/addressing"><Address>
> > http://www.w3.org/2005/08/addressing/anonymous
> </Address></ReplyTo><wsse:Security
> > xmlns:wsse="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> > xmlns:wsu="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> > soap:mustUnderstand="true"><wsu:Timestamp
> >
> wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
> >
> wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
> > Type="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
> > xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust
> "><wst:RequestType>
> > http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
> </wst:RequestType><wsp:AppliesTo
> > xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
> > xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
> > https://localhost:8443/jaxws-sc/simple
> </wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
> > xmlns:wsu="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> >
> "><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> </wst:TokenType><wst:Entropy><wst:BinarySecret
> > Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
> >
> ">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
> >
> </wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
> >
> > 2) Then look for "Inbound Message" : the Metro service response, which is
> > the RSTR/SCT (HTTP status code 200). So far so good:
> >
> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
> > http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
> > xmlns:wsse="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> > xmlns:wsu="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
> > http://www.w3.org/2005/08/addressing">
> > http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</Action><MessageID
> > xmlns="http://www.w3.org/2005/08/addressing
> ">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
> > xmlns="http://www.w3.org/2005/08/addressing
> ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
> > xmlns="http://www.w3.org/2005/08/addressing">
> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
> > xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/"
> >
> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
> > xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:ns6="
> > http://www.w3.org/2005/08/addressing" xmlns:ns7="
> > http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
> > http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:ns9="
> > http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
> > http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
> > http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> </ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
> >
> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> "/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
> > URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> >
> "/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
> > http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
> </ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
> > ns5:Type="BinarySecret"><ns5:BinarySecret Type="
> > http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
> >
> ">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
> >
> > 3) Then the client request with the SCT to the application (ID: 2):
> >
> > <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope
> "><soap:Header><Action
> > xmlns="http://www.w3.org/2005/08/addressing">http://xmlsoap.org/Ping
> </Action><MessageID
> > xmlns="http://www.w3.org/2005/08/addressing
> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
> > xmlns="http://www.w3.org/2005/08/addressing">
> > https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
> > http://www.w3.org/2005/08/addressing"><Address>
> > http://www.w3.org/2005/08/addressing/anonymous
> </Address></ReplyTo><wsse:Security
> > xmlns:wsse="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> > xmlns:wsu="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> > soap:mustUnderstand="true"><wsu:Timestamp
> >
> wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
> > xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> >
> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
> > Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
> > http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
> Algorithm="
> > http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
> > URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
> > http://www.w3.org/2001/10/xml-exc-c14n#
> "/></ds:Transforms><ds:DigestMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
> "/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
> > Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
> > xmlns:wsse="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "><wsse:Reference
> > URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
> > http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> "/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
> > xmlns="http://xmlsoap.org/Ping
> >
> "><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
> >
> > 4) Finally, the Metro service response which is a SOAP fault (HTTP status
> > code 500):
> >
> > <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
> > http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> > xmlns:wsu="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
> > http://www.w3.org/2005/08/addressing">
> > http://www.w3.org/2005/08/addressing/fault</Action><MessageID xmlns="
> > http://www.w3.org/2005/08/addressing
> ">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
> > xmlns="http://www.w3.org/2005/08/addressing
> ">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
> > xmlns="http://www.w3.org/2005/08/addressing">
> > http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
> > S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
> > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
> > xmlns:ns13="http://schemas.xmlsoap.org/soap/envelope/"
> >
> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
> > xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/
> "><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
> > xmlns:wsse="
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> ">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
> > xml:lang="en">Invalid Security
> > Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
> >
> > Regards,
> > Cyril
> >
> > On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dm...@sosnoski.com>
> wrote:
> >
> >> Hi Cyril,
> >>
> >> I've also experienced problems with Metro rejecting the signature when
> >> using WS-SC. I was using the trunk code, though, so assumed it was
> probably
> >> a new issue with all the 3.0 changes.
> >>
> >> Are you getting some messages through successfully before the failure?
> >> I'm asking because you say the "final service call" is where the problem
> >> occurs. The failure I was seeing was on the first message using the SC
> >> token.
> >>
> >> Colm, sorry I never supplied the test case for this to you. I'll get
> that
> >> in this weekend.
> >>
> >> - Dennis
> >>
> >> Dennis M. Sosnoski
> >> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
> >> CXF and Web Services Security Training <http://www.sosnoski.com/
> >> training.html>
> >> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
> >>
> >>
> >> On 12/21/2013 12:54 PM, Cyril wrote:
> >>
> >>> Hello,
> >>> I have attached again the CXF client log (cxf_client.log.txt). Did you
> >>> get jaxws-sc.wsdl and client-cxf.xml?
> >>> Thank you for your help.
> >>>
> >>> Regards,
> >>> Cyril
> >>>
> >>>
> >>>
> >>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
> >>> coheigea@apache.org <ma...@apache.org>> wrote:
> >>>
> >>> Hi Cyril,
> >>>
> >>> It appears you didn't attach the logs, could you resend them
> >>> please + I
> >>> will take a look? The FINE error logs you posted in the message
> >>> are a red
> >>> herring, this just means that CXF did not explicitly mark certain
> >>> policies
> >>> are being asserted.
> >>>
> >>> Colm.
> >>>
> >>>
> >>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
> >>> <ma...@gmail.com>> wrote:
> >>>
> >>> > Hello,
> >>> > I am trying to have a WS-SecureConversation between a CXF client
> >>> - version
> >>> > 2.7.6 - talking to a Metro service with WS-SecureConversation
> >>> (over SSL
> >>> > TransportBinding). When CXF makes the final service call with the
> >>> > SecurityContextToken in the security header, the service replies
> >>> a SOAP
> >>> > fault "Invalid Security Header". The service logs say the
> Signature
> >>> > Verification for Signature with ID SIG-4 failed. I am trying to
> >>> investigate
> >>> > more on the service side what is wrong with the signature.
> >>> However, I
> >>> > noticed the following exceptions in CXF in FINE log level:
> >>> >
> >>> > Dec 19, 2013 6:37:08 PM
> >>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
> >>> > FINE: An exception was thrown when verifying that the effective
> >>> policy for
> >>> > this request was satisfied. However, this exception will not
> >>> result in a
> >>> > fault. The exception raised is:
> >>> org.apache.cxf.ws.policy.PolicyException:
> >>> > These policy alternatives can not be satisfied:
> >>> >
> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>> 200702}SignedParts
> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>> 200702%7DSignedParts>
> >>> >
> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>> 200702}EncryptedParts
> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>> 200702%7DEncryptedParts>
> >>> >
> >>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>> 200702}TransportToken
> >>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
> >>> 200702%7DTransportToken>
> >>> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
> >>> <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
> >>>
> >>> >
> >>> > Could this be an issue? Better ideas?
> >>> >
> >>> > I have attached the service WSDL, and the CXF client (Spring)
> >>> > configuration and debug logs with the requests/responses.
> >>> >
> >>> > Thanks for any help.
> >>> >
> >>> > Regards,
> >>> > Cyril
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Colm O hEigeartaigh
> >>>
> >>> Talend Community Coder
> >>> http://coders.talend.com
> >>>
> >>>
> >>>
> >>
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
Could you try with CXF 2.7.8 to see if it works? Could you also send debug
logging of the service side? It looks like the problem might be that the
client + service might be deriving the secret keys in different ways. I
fixed some issues on trunk relating to this, but I'm not sure if there were
any fixes in 2.7.x or not.
Colm.
On Thu, Dec 26, 2013 at 1:08 PM, Cyril <co...@gmail.com> wrote:
> Hi Dennis,
>
> Yes, the issue occurs only when calling the service after the security
> context token has been successfully obtained.
>
> 1) If you look for "Outbound Message" from the beginning of the CXF client
> log attached, you'll find the first client request which is the RST/SCT
> (ID: 1):
>
> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><Action
> xmlns="http://www.w3.org/2005/08/addressing">
> http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</Action><MessageID
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
> xmlns="http://www.w3.org/2005/08/addressing">
> https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
> http://www.w3.org/2005/08/addressing"><Address>
> http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> soap:mustUnderstand="true"><wsu:Timestamp
> wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
> wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
> Type="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
> xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"><wst:RequestType>
> http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType><wsp:AppliesTo
> xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
> xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
> https://localhost:8443/jaxws-sc/simple</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
> http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType><wst:Entropy><wst:BinarySecret
> Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
> ">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
> http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
> </wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
>
> 2) Then look for "Inbound Message" : the Metro service response, which is
> the RSTR/SCT (HTTP status code 200). So far so good:
>
> <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
> http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
> http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
> http://www.w3.org/2005/08/addressing">
> http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</Action><MessageID
> xmlns="http://www.w3.org/2005/08/addressing">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
> xmlns="http://www.w3.org/2005/08/addressing">
> http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
> S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
> http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
> xmlns:ns14="http://schemas.xmlsoap.org/soap/envelope/"
> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
> xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:ns6="
> http://www.w3.org/2005/08/addressing" xmlns:ns7="
> http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
> http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:ns9="
> http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
> http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
> http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
> http://schemas.xmlsoap.org/ws/2005/02/sc/sct</ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
> URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
> http://schemas.xmlsoap.org/ws/2005/02/sc/sct"/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
> URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
> http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> "/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
> http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1</ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
> ns5:Type="BinarySecret"><ns5:BinarySecret Type="
> http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
> ">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
>
> 3) Then the client request with the SCT to the application (ID: 2):
>
> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><Action
> xmlns="http://www.w3.org/2005/08/addressing">http://xmlsoap.org/Ping</Action><MessageID
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
> xmlns="http://www.w3.org/2005/08/addressing">
> https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
> http://www.w3.org/2005/08/addressing"><Address>
> http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> soap:mustUnderstand="true"><wsu:Timestamp
> wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
> xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
> Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="
> http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
> URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
> Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
> URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
> http://schemas.xmlsoap.org/ws/2005/02/sc/sct"/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
> xmlns="http://xmlsoap.org/Ping
> "><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
>
> 4) Finally, the Metro service response which is a SOAP fault (HTTP status
> code 500):
>
> <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
> http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
> http://www.w3.org/2005/08/addressing">
> http://www.w3.org/2005/08/addressing/fault</Action><MessageID xmlns="
> http://www.w3.org/2005/08/addressing">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
> xmlns="http://www.w3.org/2005/08/addressing">
> http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
> S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
> http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
> xmlns:ns13="http://schemas.xmlsoap.org/soap/envelope/"
> wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
> xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/"><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
> xml:lang="en">Invalid Security
> Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
>
> Regards,
> Cyril
>
> On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
>> Hi Cyril,
>>
>> I've also experienced problems with Metro rejecting the signature when
>> using WS-SC. I was using the trunk code, though, so assumed it was probably
>> a new issue with all the 3.0 changes.
>>
>> Are you getting some messages through successfully before the failure?
>> I'm asking because you say the "final service call" is where the problem
>> occurs. The failure I was seeing was on the first message using the SC
>> token.
>>
>> Colm, sorry I never supplied the test case for this to you. I'll get that
>> in this weekend.
>>
>> - Dennis
>>
>> Dennis M. Sosnoski
>> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
>> CXF and Web Services Security Training <http://www.sosnoski.com/
>> training.html>
>> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>>
>>
>> On 12/21/2013 12:54 PM, Cyril wrote:
>>
>>> Hello,
>>> I have attached again the CXF client log (cxf_client.log.txt). Did you
>>> get jaxws-sc.wsdl and client-cxf.xml?
>>> Thank you for your help.
>>>
>>> Regards,
>>> Cyril
>>>
>>>
>>>
>>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
>>> coheigea@apache.org <ma...@apache.org>> wrote:
>>>
>>> Hi Cyril,
>>>
>>> It appears you didn't attach the logs, could you resend them
>>> please + I
>>> will take a look? The FINE error logs you posted in the message
>>> are a red
>>> herring, this just means that CXF did not explicitly mark certain
>>> policies
>>> are being asserted.
>>>
>>> Colm.
>>>
>>>
>>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> > Hello,
>>> > I am trying to have a WS-SecureConversation between a CXF client
>>> - version
>>> > 2.7.6 - talking to a Metro service with WS-SecureConversation
>>> (over SSL
>>> > TransportBinding). When CXF makes the final service call with the
>>> > SecurityContextToken in the security header, the service replies
>>> a SOAP
>>> > fault "Invalid Security Header". The service logs say the Signature
>>> > Verification for Signature with ID SIG-4 failed. I am trying to
>>> investigate
>>> > more on the service side what is wrong with the signature.
>>> However, I
>>> > noticed the following exceptions in CXF in FINE log level:
>>> >
>>> > Dec 19, 2013 6:37:08 PM
>>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
>>> > FINE: An exception was thrown when verifying that the effective
>>> policy for
>>> > this request was satisfied. However, this exception will not
>>> result in a
>>> > fault. The exception raised is:
>>> org.apache.cxf.ws.policy.PolicyException:
>>> > These policy alternatives can not be satisfied:
>>> >
>>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> 200702}SignedParts
>>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> 200702%7DSignedParts>
>>> >
>>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> 200702}EncryptedParts
>>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> 200702%7DEncryptedParts>
>>> >
>>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> 200702}TransportToken
>>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>>> 200702%7DTransportToken>
>>> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
>>> <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
>>>
>>> >
>>> > Could this be an issue? Better ideas?
>>> >
>>> > I have attached the service WSDL, and the CXF client (Spring)
>>> > configuration and debug logs with the requests/responses.
>>> >
>>> > Thanks for any help.
>>> >
>>> > Regards,
>>> > Cyril
>>> >
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>>
>>>
>>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Cyril <co...@gmail.com>.
Hi Dennis,
Yes, the issue occurs only when calling the service after the security
context token has been successfully obtained.
1) If you look for "Outbound Message" from the beginning of the CXF client
log attached, you'll find the first client request which is the RST/SCT
(ID: 1):
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><Action
xmlns="http://www.w3.org/2005/08/addressing">
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</Action><MessageID
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</MessageID><To
xmlns="http://www.w3.org/2005/08/addressing">
https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
http://www.w3.org/2005/08/addressing"><Address>
http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:Security
xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
soap:mustUnderstand="true"><wsu:Timestamp
wsu:Id="TS-1"><wsu:Created>2013-12-19T17:37:08.811Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.811Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken
wsu:Id="UsernameToken-2"><wsse:Username>alice</wsse:Username><wsse:Password
Type="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">alice</wsse:Password></wsse:UsernameToken></wsse:Security></soap:Header><soap:Body><wst:RequestSecurityToken
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"><wst:RequestType>
http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType><wsp:AppliesTo
xmlns:wsp="http://www.w3.org/ns/ws-policy"><wsa:EndpointReference
xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Address>
https://localhost:8443/jaxws-sc/simple</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:Lifetime
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
"><wsu:Created>2013-12-19T17:37:08.483Z</wsu:Created><wsu:Expires>2013-12-19T17:42:08.483Z</wsu:Expires></wst:Lifetime><wst:TokenType>
http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType><wst:Entropy><wst:BinarySecret
Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
">AFZpAMpiJYRhoWdGIs0dIMYD0Ugr2n5Bdgpo9prqdCE=</wst:BinarySecret></wst:Entropy><wst:ComputedKeyAlgorithm>
http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
</wst:ComputedKeyAlgorithm><wst:Renewing/></wst:RequestSecurityToken></soap:Body></soap:Envelope>
2) Then look for "Inbound Message" : the Metro service response, which is
the RSTR/SCT (HTTP status code 200). So far so good:
<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
http://www.w3.org/2003/05/soap-envelope" xmlns:wsse11="
http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
http://www.w3.org/2005/08/addressing">
http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</Action><MessageID
xmlns="http://www.w3.org/2005/08/addressing">uuid:39d1c0a1-29c4-418f-9ae1-9f628e48ae25</MessageID><RelatesTo
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03</RelatesTo><To
xmlns="http://www.w3.org/2005/08/addressing">
http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
S:mustUnderstand="true"><wsu:Timestamp xmlns:ns15="
http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns14="
http://schemas.xmlsoap.org/soap/envelope/"
wsu:Id="_1"><wsu:Created>2013-12-19T17:37:09Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><ns5:RequestSecurityTokenResponse
xmlns:ns5="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:ns6="
http://www.w3.org/2005/08/addressing" xmlns:ns7="
http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:ns8="
http://schemas.xmlsoap.org/ws/2006/02/addressingidentity" xmlns:ns9="
http://www.w3.org/2000/09/xmldsig#" xmlns:ns10="
http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:ns11="
http://www.w3.org/2001/10/xml-exc-c14n#"><ns5:TokenType>
http://schemas.xmlsoap.org/ws/2005/02/sc/sct</ns5:TokenType><ns5:RequestedSecurityToken><ns7:SecurityContextToken
wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken></ns5:RequestedSecurityToken><ns5:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:Reference
URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
http://schemas.xmlsoap.org/ws/2005/02/sc/sct"/></wsse:SecurityTokenReference></ns5:RequestedAttachedReference><ns5:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:Reference
URI="urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e" ValueType="
http://schemas.xmlsoap.org/ws/2005/02/sc/sct
"/></wsse:SecurityTokenReference></ns5:RequestedUnattachedReference><ns5:RequestedProofToken><ns5:ComputedKey>
http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1</ns5:ComputedKey></ns5:RequestedProofToken><ns5:Entropy
ns5:Type="BinarySecret"><ns5:BinarySecret Type="
http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce
">PvdIxpjRTwA3UHpYL6ZaSg==</ns5:BinarySecret></ns5:Entropy><ns5:Lifetime><wsu:Created>2013-12-19T17:37:09.279Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.279Z</wsu:Expires></ns5:Lifetime></ns5:RequestSecurityTokenResponse></S:Body></S:Envelope>
3) Then the client request with the SCT to the application (ID: 2):
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><Action
xmlns="http://www.w3.org/2005/08/addressing">http://xmlsoap.org/Ping</Action><MessageID
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</MessageID><To
xmlns="http://www.w3.org/2005/08/addressing">
https://localhost:8443/jaxws-sc/simple</To><ReplyTo xmlns="
http://www.w3.org/2005/08/addressing"><Address>
http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo><wsse:Security
xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
soap:mustUnderstand="true"><wsu:Timestamp
wsu:Id="TS-3"><wsu:Created>2013-12-19T17:37:09.528Z</wsu:Created><wsu:Expires>2013-12-19T17:42:09.528Z</wsu:Expires></wsu:Timestamp><ns7:SecurityContextToken
xmlns:ns7="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a"><ns7:Identifier>urn:uuid:ed4c9af8-7b6f-4045-91c8-f1ba88e3a27e</ns7:Identifier></ns7:SecurityContextToken><ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Id="SIG-4"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="
http://www.w3.org/2000/09/xmldsig#hmac-sha1"/><ds:Reference
URI="#TS-3"><ds:Transforms><ds:Transform Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>pHZcwRLFIoWm72NiCQomYNJifqE=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ErXjaqZ1EAy+PLxNxT9NwvKX9aI=</ds:SignatureValue><ds:KeyInfo
Id="KI-7244D1435FEC3FC98A13874746295441"><wsse:SecurityTokenReference
xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Reference
URI="#uuid-b0ac90e4-dfe7-4ea8-8c6a-0aff80c45b4a" ValueType="
http://schemas.xmlsoap.org/ws/2005/02/sc/sct"/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></soap:Header><soap:Body><Ping
xmlns="http://xmlsoap.org/Ping
"><scenario>1</scenario><origin>sun</origin><text>Passed!</text></Ping></soap:Body></soap:Envelope>
4) Finally, the Metro service response which is a SOAP fault (HTTP status
code 500):
<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="
http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><Action xmlns="
http://www.w3.org/2005/08/addressing">
http://www.w3.org/2005/08/addressing/fault</Action><MessageID xmlns="
http://www.w3.org/2005/08/addressing">uuid:d47aab2c-f23d-41a1-88d8-78b4873858a9</MessageID><RelatesTo
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:1f037be0-d11b-42ea-b785-f2aa8b3db951</RelatesTo><To
xmlns="http://www.w3.org/2005/08/addressing">
http://www.w3.org/2005/08/addressing/anonymous</To><wsse:Security
S:mustUnderstand="true"><wsu:Timestamp xmlns:ns14="
http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns13="
http://schemas.xmlsoap.org/soap/envelope/"
wsu:Id="_1"><wsu:Created>2013-12-19T17:37:12Z</wsu:Created><wsu:Expires>2013-12-19T17:42:12Z</wsu:Expires></wsu:Timestamp></wsse:Security></S:Header><S:Body><S:Fault
xmlns:ns4="http://schemas.xmlsoap.org/soap/envelope/"><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value
xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">wsse:InvalidSecurity</S:Value></S:Subcode></S:Code><S:Reason><S:Text
xml:lang="en">Invalid Security
Header</S:Text></S:Reason></S:Fault></S:Body></S:Envelope>
Regards,
Cyril
On Sat, Dec 21, 2013 at 3:30 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Hi Cyril,
>
> I've also experienced problems with Metro rejecting the signature when
> using WS-SC. I was using the trunk code, though, so assumed it was probably
> a new issue with all the 3.0 changes.
>
> Are you getting some messages through successfully before the failure? I'm
> asking because you say the "final service call" is where the problem
> occurs. The failure I was seeing was on the first message using the SC
> token.
>
> Colm, sorry I never supplied the test case for this to you. I'll get that
> in this weekend.
>
> - Dennis
>
> Dennis M. Sosnoski
> Java Web Services Consulting <http://www.sosnoski.com/consult.html>
> CXF and Web Services Security Training <http://www.sosnoski.com/
> training.html>
> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>
>
> On 12/21/2013 12:54 PM, Cyril wrote:
>
>> Hello,
>> I have attached again the CXF client log (cxf_client.log.txt). Did you
>> get jaxws-sc.wsdl and client-cxf.xml?
>> Thank you for your help.
>>
>> Regards,
>> Cyril
>>
>>
>>
>> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh <
>> coheigea@apache.org <ma...@apache.org>> wrote:
>>
>> Hi Cyril,
>>
>> It appears you didn't attach the logs, could you resend them
>> please + I
>> will take a look? The FINE error logs you posted in the message
>> are a red
>> herring, this just means that CXF did not explicitly mark certain
>> policies
>> are being asserted.
>>
>> Colm.
>>
>>
>> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> > Hello,
>> > I am trying to have a WS-SecureConversation between a CXF client
>> - version
>> > 2.7.6 - talking to a Metro service with WS-SecureConversation
>> (over SSL
>> > TransportBinding). When CXF makes the final service call with the
>> > SecurityContextToken in the security header, the service replies
>> a SOAP
>> > fault "Invalid Security Header". The service logs say the Signature
>> > Verification for Signature with ID SIG-4 failed. I am trying to
>> investigate
>> > more on the service side what is wrong with the signature.
>> However, I
>> > noticed the following exceptions in CXF in FINE log level:
>> >
>> > Dec 19, 2013 6:37:08 PM
>> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
>> > FINE: An exception was thrown when verifying that the effective
>> policy for
>> > this request was satisfied. However, this exception will not
>> result in a
>> > fault. The exception raised is:
>> org.apache.cxf.ws.policy.PolicyException:
>> > These policy alternatives can not be satisfied:
>> >
>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> 200702}SignedParts
>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> 200702%7DSignedParts>
>> >
>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> 200702}EncryptedParts
>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> 200702%7DEncryptedParts>
>> >
>> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> 200702}TransportToken
>> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/
>> 200702%7DTransportToken>
>> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
>> <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
>>
>> >
>> > Could this be an issue? Better ideas?
>> >
>> > I have attached the service WSDL, and the CXF client (Spring)
>> > configuration and debug logs with the requests/responses.
>> >
>> > Thanks for any help.
>> >
>> > Regards,
>> > Cyril
>> >
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Cyril,
I've also experienced problems with Metro rejecting the signature when
using WS-SC. I was using the trunk code, though, so assumed it was
probably a new issue with all the 3.0 changes.
Are you getting some messages through successfully before the failure?
I'm asking because you say the "final service call" is where the problem
occurs. The failure I was seeing was on the first message using the SC
token.
Colm, sorry I never supplied the test case for this to you. I'll get
that in this weekend.
- Dennis
Dennis M. Sosnoski
Java Web Services Consulting <http://www.sosnoski.com/consult.html>
CXF and Web Services Security Training
<http://www.sosnoski.com/training.html>
Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
On 12/21/2013 12:54 PM, Cyril wrote:
> Hello,
> I have attached again the CXF client log (cxf_client.log.txt). Did you
> get jaxws-sc.wsdl and client-cxf.xml?
> Thank you for your help.
>
> Regards,
> Cyril
>
>
>
> On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh
> <coheigea@apache.org <ma...@apache.org>> wrote:
>
> Hi Cyril,
>
> It appears you didn't attach the logs, could you resend them
> please + I
> will take a look? The FINE error logs you posted in the message
> are a red
> herring, this just means that CXF did not explicitly mark certain
> policies
> are being asserted.
>
> Colm.
>
>
> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <coder103@gmail.com
> <ma...@gmail.com>> wrote:
>
> > Hello,
> > I am trying to have a WS-SecureConversation between a CXF client
> - version
> > 2.7.6 - talking to a Metro service with WS-SecureConversation
> (over SSL
> > TransportBinding). When CXF makes the final service call with the
> > SecurityContextToken in the security header, the service replies
> a SOAP
> > fault "Invalid Security Header". The service logs say the Signature
> > Verification for Signature with ID SIG-4 failed. I am trying to
> investigate
> > more on the service side what is wrong with the signature.
> However, I
> > noticed the following exceptions in CXF in FINE log level:
> >
> > Dec 19, 2013 6:37:08 PM
> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
> > FINE: An exception was thrown when verifying that the effective
> policy for
> > this request was satisfied. However, this exception will not
> result in a
> > fault. The exception raised is:
> org.apache.cxf.ws.policy.PolicyException:
> > These policy alternatives can not be satisfied:
> >
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702%7DSignedParts>
> >
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702%7DEncryptedParts>
> >
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
> <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702%7DTransportToken>
> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
> <http://schemas.xmlsoap.org/ws/2005/07/securitypolicy%7DTrust10>
> >
> > Could this be an issue? Better ideas?
> >
> > I have attached the service WSDL, and the CXF client (Spring)
> > configuration and debug logs with the requests/responses.
> >
> > Thanks for any help.
> >
> > Regards,
> > Cyril
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Cyril <co...@gmail.com>.
Hello,
I have attached again the CXF client log (cxf_client.log.txt). Did you get
jaxws-sc.wsdl and client-cxf.xml?
Thank you for your help.
Regards,
Cyril
On Fri, Dec 20, 2013 at 11:48 AM, Colm O hEigeartaigh
<co...@apache.org>wrote:
> Hi Cyril,
>
> It appears you didn't attach the logs, could you resend them please + I
> will take a look? The FINE error logs you posted in the message are a red
> herring, this just means that CXF did not explicitly mark certain policies
> are being asserted.
>
> Colm.
>
>
> On Thu, Dec 19, 2013 at 5:45 PM, Cyril <co...@gmail.com> wrote:
>
> > Hello,
> > I am trying to have a WS-SecureConversation between a CXF client -
> version
> > 2.7.6 - talking to a Metro service with WS-SecureConversation (over SSL
> > TransportBinding). When CXF makes the final service call with the
> > SecurityContextToken in the security header, the service replies a SOAP
> > fault "Invalid Security Header". The service logs say the Signature
> > Verification for Signature with ID SIG-4 failed. I am trying to
> investigate
> > more on the service side what is wrong with the signature. However, I
> > noticed the following exceptions in CXF in FINE log level:
> >
> > Dec 19, 2013 6:37:08 PM
> > org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
> > FINE: An exception was thrown when verifying that the effective policy
> for
> > this request was satisfied. However, this exception will not result in a
> > fault. The exception raised is:
> org.apache.cxf.ws.policy.PolicyException:
> > These policy alternatives can not be satisfied:
> > {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
> > {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
> > {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
> > {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
> >
> > Could this be an issue? Better ideas?
> >
> > I have attached the service WSDL, and the CXF client (Spring)
> > configuration and debug logs with the requests/responses.
> >
> > Thanks for any help.
> >
> > Regards,
> > Cyril
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to
Metro service)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Cyril,
It appears you didn't attach the logs, could you resend them please + I
will take a look? The FINE error logs you posted in the message are a red
herring, this just means that CXF did not explicitly mark certain policies
are being asserted.
Colm.
On Thu, Dec 19, 2013 at 5:45 PM, Cyril <co...@gmail.com> wrote:
> Hello,
> I am trying to have a WS-SecureConversation between a CXF client - version
> 2.7.6 - talking to a Metro service with WS-SecureConversation (over SSL
> TransportBinding). When CXF makes the final service call with the
> SecurityContextToken in the security header, the service replies a SOAP
> fault "Invalid Security Header". The service logs say the Signature
> Verification for Signature with ID SIG-4 failed. I am trying to investigate
> more on the service side what is wrong with the signature. However, I
> noticed the following exceptions in CXF in FINE log level:
>
> Dec 19, 2013 6:37:08 PM
> org.apache.cxf.ws.policy.PolicyVerificationOutInterceptor handle
> FINE: An exception was thrown when verifying that the effective policy for
> this request was satisfied. However, this exception will not result in a
> fault. The exception raised is: org.apache.cxf.ws.policy.PolicyException:
> These policy alternatives can not be satisfied:
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
> {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}Trust10
>
> Could this be an issue? Better ideas?
>
> I have attached the service WSDL, and the CXF client (Spring)
> configuration and debug logs with the requests/responses.
>
> Thanks for any help.
>
> Regards,
> Cyril
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com