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 <coder...@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 > <cohei...@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 <coder...@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 <d...@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 < >> >>> cohei...@apache.org <mailto:cohei...@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 <coder...@gmail.com >> >>> <mailto:coder...@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
