You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jesper Nygårds <je...@gmail.com> on 2012/10/17 14:24:35 UTC
Problem with c14n
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?
Re: Problem with c14n
Posted by Jesper Nygårds <je...@gmail.com>.
On Fri, Oct 19, 2012 at 12:29 PM, Colm O hEigeartaigh
<co...@apache.org> wrote:
> When you are creating the SSEK Element you need to also add the ssek
> namespace to the element, e.g.:
>
Oh, I see the problem. Thank you so much for your help.
Jesper
Re: Problem with c14n
Posted by Colm O hEigeartaigh <co...@apache.org>.
When you are creating the SSEK Element you need to also add the ssek
namespace to the element, e.g.:
Element SSEK =
doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
"ssek:SSEK");
SSEK.setAttributeNS("http://www.w3.org/2000/xmlns/", "xmlns:ssek", "
http://schemas.ssek.org/ssek/2006-05-10/");
Doing this instead of adding the workaround should solve the problem.
Colm.
On Fri, Oct 19, 2012 at 8:37 AM, Jesper Nygårds <je...@gmail.com>wrote:
> On Thu, Oct 18, 2012 at 3:56 PM, Daniel Kulp <dk...@apache.org> wrote:
> > It really could be just about anywhere. Can I ask to see the
> > code that is creating the seek:SSEK header?
>
> Here's the relevant code. The line within the try/catch is our
> workaround to this problem: adding it makes the ssek namespace appear
> in the canonicalized fragment, but without it we have the problem I
> reported.
>
> SOAPMessage soapMessage = message.getContent(SOAPMessage.class);
>
> try {
> // Adding this line worked to resolve our problem
> soapMessage.getSOAPHeader().addNamespaceDeclaration("ssek",
> "http://schemas.ssek.org/ssek/2006-05-10/");
> } catch (SOAPException e) {
> e.printStackTrace();
> }
>
>
> Document doc = soapMessage.getSOAPPart();
> if (doc.getElementsByTagNameNS("http://schemas.xmlsoap.org/soap/envelope/
> ",
> "Header").getLength() > 0){
> Node soapheader =
> doc.getElementsByTagNameNS("http://schemas.xmlsoap.org/soap/envelope/",
> "Header").item(0);
>
> Element SSEK =
> doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
> "ssek:SSEK");
> SSEK.setAttributeNS("http://schemas.xmlsoap.org/soap/envelope/",
> "soapenv:mustUnderstand", "1");
>
> Element senderIdElement =
> doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
> "ssek:SenderId");
> senderIdElement.setTextContent(senderId);
> senderIdElement.setAttribute("Type", "CN");
>
> Element recieverIdElement =
> doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
> "ssek:ReceiverId");
> recieverIdElement.setTextContent(recieverId);
> recieverIdElement.setAttribute("Type", "CN");
>
> Element txIdElement =
> doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
> "ssek:TxId");
> txIdElement.setTextContent(UUID.randomUUID().toString());
>
> SSEK.appendChild(senderIdElement);
> SSEK.appendChild(recieverIdElement);
> SSEK.appendChild(txIdElement);
>
> soapheader.appendChild(SSEK);
> }
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Problem with c14n
Posted by Jesper Nygårds <je...@gmail.com>.
On Thu, Oct 18, 2012 at 3:56 PM, Daniel Kulp <dk...@apache.org> wrote:
> It really could be just about anywhere. Can I ask to see the
> code that is creating the seek:SSEK header?
Here's the relevant code. The line within the try/catch is our
workaround to this problem: adding it makes the ssek namespace appear
in the canonicalized fragment, but without it we have the problem I
reported.
SOAPMessage soapMessage = message.getContent(SOAPMessage.class);
try {
// Adding this line worked to resolve our problem
soapMessage.getSOAPHeader().addNamespaceDeclaration("ssek",
"http://schemas.ssek.org/ssek/2006-05-10/");
} catch (SOAPException e) {
e.printStackTrace();
}
Document doc = soapMessage.getSOAPPart();
if (doc.getElementsByTagNameNS("http://schemas.xmlsoap.org/soap/envelope/",
"Header").getLength() > 0){
Node soapheader =
doc.getElementsByTagNameNS("http://schemas.xmlsoap.org/soap/envelope/",
"Header").item(0);
Element SSEK =
doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
"ssek:SSEK");
SSEK.setAttributeNS("http://schemas.xmlsoap.org/soap/envelope/",
"soapenv:mustUnderstand", "1");
Element senderIdElement =
doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
"ssek:SenderId");
senderIdElement.setTextContent(senderId);
senderIdElement.setAttribute("Type", "CN");
Element recieverIdElement =
doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
"ssek:ReceiverId");
recieverIdElement.setTextContent(recieverId);
recieverIdElement.setAttribute("Type", "CN");
Element txIdElement =
doc.createElementNS("http://schemas.ssek.org/ssek/2006-05-10/",
"ssek:TxId");
txIdElement.setTextContent(UUID.randomUUID().toString());
SSEK.appendChild(senderIdElement);
SSEK.appendChild(recieverIdElement);
SSEK.appendChild(txIdElement);
soapheader.appendChild(SSEK);
}
Re: Problem with c14n
Posted by Daniel Kulp <dk...@apache.org>.
On Oct 18, 2012, at 2:14 AM, Jesper Nygårds <je...@gmail.com> 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 <dk...@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 <je...@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
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Problem with c14n
Posted by Jesper Nygårds <je...@gmail.com>.
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 <dk...@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 <je...@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
>
Re: Problem with c14n
Posted by Daniel Kulp <dk...@apache.org>.
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 <je...@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