This definitely looks like a bug to me. That's likely all the way down in santuario though. I believe that's where the c14n stuff is done.
Can you at least double check that the xmlsec jar is 1.5.2? Dan On Oct 17, 2012, at 8:24 AM, Jesper Nygårds <[email protected]> wrote: > I am using CXF 2.6.3 > > I am developing a web service client/server, using WS-Security and > SSEK, which is a Swedish specification adding some security related > information to the message. In our solution, three parts of our client > request are supposed to be signed: the timestamp, our SSEK header, and > the body. The organization we're communicating with was reporting that > the digest of our SSEK header was not correct. This is what our > request looked like (formatted for readability and somewhat edited): > > <soapenv:Envelope > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:ns="http://schema.forsakringskassan.se/tjanstepensionsbolag/1";> > <soapenv:Header> > <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"; > soapenv:mustUnderstand="1"> > <wsse:BinarySecurityToken > EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"; > ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"; > wsu:Id="X509-643E9C889F7DEEDB6613503933329164">YgXlw+8H3q5O2dvinH7FSY=</wsse:BinarySecurityToken> > <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="SIG-8"> > <ds:SignedInfo> > <ds:CanonicalizationMethod > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";> > <ec:InclusiveNamespaces > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="ns > soapenv"/> > </ds:CanonicalizationMethod> > <ds:SignatureMethod > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > <ds:Reference URI="#TS-5"> > <ds:Transforms> > <ds:Transform > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";> > <ec:InclusiveNamespaces > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="wsse ns > soapenv"/> > </ds:Transform> > </ds:Transforms> > <ds:DigestMethod > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > <ds:DigestValue>S+Xd8ANIW02EhOYJYWlKDrWQhgg=</ds:DigestValue> > </ds:Reference> > <ds:Reference URI="#id-6"> > <ds:Transforms> > <ds:Transform > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";> > <ec:InclusiveNamespaces > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="ns"/> > </ds:Transform> > </ds:Transforms> > <ds:DigestMethod > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > <ds:DigestValue>BvQw2HBJxbYLaaqI4NLQJxwQFJ8=</ds:DigestValue> > </ds:Reference> > <ds:Reference URI="#id-7"> > <ds:Transforms> > <ds:Transform > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";> > <ec:InclusiveNamespaces > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="ns"/> > </ds:Transform> > </ds:Transforms> > <ds:DigestMethod > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > <ds:DigestValue>Djj+z3X+hd3h5cZkePdkIZZg0Zs=</ds:DigestValue> > </ds:Reference> > </ds:SignedInfo> > > <ds:SignatureValue>Qp89XS2pWW8MGLv9w8ZXsXXGJAfkSd1J335qpnYOKdimwXv6dmFWm2UqukKfI/nff+JCuUPLHkraTXEhfNrDzjXoZ4YgOYF11zpsjIW3SLulQWjuzT4Z94FKsV7g6/L7V+K0JcqxU+NvQ9kJrQOG9W6SdlyPH4AIUaz484zifhk=</ds:SignatureValue> > <ds:KeyInfo Id="KI-643E9C889F7DEEDB6613503933329175"> > <wsse:SecurityTokenReference > wsu:Id="STR-643E9C889F7DEEDB6613503933329176"> > <wsse:Reference > URI="#X509-643E9C889F7DEEDB6613503933329164" > ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/> > </wsse:SecurityTokenReference> > </ds:KeyInfo> > </ds:Signature> > <wsu:Timestamp > wsu:Id="TS-5"><wsu:Created>2012-10-16T13:15:32.916Z</wsu:Created><wsu:Expires>2012-10-16T16:15:32.916Z</wsu:Expires></wsu:Timestamp> > </wsse:Security> > <ssek:SSEK > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > soapenv:mustUnderstand="1" wsu:Id="id-7" > xmlns:ssek="http://schemas.ssek.org/ssek/2006-05-10/";><ssek:SenderId > Type="CN">SENDER</ssek:SenderId><ssek:ReceiverId > Type="CN">RECEIVER</ssek:ReceiverId><ssek:TxId>1</ssek:TxId></ssek:SSEK> > </soapenv:Header> > <soapenv:Body > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > wsu:Id="id-6"> > <ns:STPFragaSvar> > <ns:svar> > <ns:grunduppgifter> > <ns:id>1</ns:id> > <ns:pnr>197011101234</ns:pnr> > </ns:grunduppgifter> > <ns:uppgiftKanEjLamnas/> > </ns:svar> > </ns:STPFragaSvar> > </soapenv:Body> > </soapenv:Envelope> > > After quite a few hours of debugging, I found out that after the > requested Exclusive Canonicalization, CXF (and its underlying > components) creates the following canonicalized SSEK header, that it > then makes a digest of: > > <ssek:SSEK > xmlns:ns="http://schema.forsakringskassan.se/tjanstepensionsbolag/1"; > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > wsu:Id="id-83" soapenv:mustUnderstand="1"><ssek:SenderId > Type="CN">SENDER</ssek:SenderId><ssek:ReceiverId > Type="CN">RECEIVER</ssek:ReceiverId><ssek:TxId>1</ssek:TxId></ssek:SSEK> > > Notice how the ns namespace declaration has been added (which is > correct, since it is on the list of InclusiveNamespaces), as well as > the soapenv namespace declaration (which is also correct, since an > attribute uses it), but the ssek namespace declaration has > disappeared. This was causing our problem with an incorrect digest, > and I must say it does look incorrect to me. Surely the ssek namespace > declaration should be included, as it is used in the element? Is this > a known problem with the c14n code, or have I misunderstood something? -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
