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 <[email protected]> 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 > <[email protected]>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 <[email protected]> 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 < >>> [email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 < >>>> >>> [email protected] <mailto:[email protected]>> 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 <[email protected] >>>> >>> <mailto:[email protected]>> 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
