On Oct 18, 2012, at 2:14 AM, Jesper Nygårds <[email protected]> wrote:
> Yes, I am using xmlsec 1.5.2. So, do I understand you correctly that > this better be reported to the Apache Santuario project's Issue > Tracking? It really could be just about anywhere. Can I ask to see the code that is creating the seek:SSEK header? Is that a JAXB object or a DOM Element or similar? If it's a DOM element, can I see the full code that is creating that? If it's DOM and not using the proper createElementNS calls, it's possible that Santuario may not be able to determine the prefix/namespaces from it. Of course, it could also be in the methods CXF uses to copy the header object into the SAAJ model that is passed into WSS4J and then Santuario. At the very least, that would help with creating a test case. Dan > > Jesper > > > On Wed, Oct 17, 2012 at 9:38 PM, Daniel Kulp <[email protected]> wrote: >> >> 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 >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
