cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Nygårds <jesper.nyga...@gmail.com>
Subject Re: Problem with c14n
Date Thu, 18 Oct 2012 06:14:23 GMT
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?

Jesper


On Wed, Oct 17, 2012 at 9:38 PM, Daniel Kulp <dkulp@apache.org> 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 <jesper.nygards@gmail.com> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Mime
View raw message