santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Krapf <lkr...@adobe.com>
Subject XMLCipher digest / serialization problem
Date Fri, 22 Aug 2014 11:38:05 GMT
Hello xmlsec

I have a weird problem with XML decryption of a SAML assertion (digest
mismatch), and have really hit a wall here. Maybe you have a hint for
me. This worked fine in xmlsec 1.4.4 but after upgrading to 2.0.1 (Java,
in an OSGi environment) signature verification fails because of a digest
mismatch.

Here is what happens, as far as I understand it (please correct me if
I'm missing something):

1) I call XMLCipher.doFinal() on an EncryptedAssertion element
2) The contents are first decrypted to a byte-array, which is then
passed to AbstractSerializer.createContext() which wraps a <dummy>
element around it, traverses the elements up to the root node and adds
all parent namespaces to it.

So now we have something like this (the xmlns attributes in <dummy> come
from the parent samlp:Response element):

<dummy xmlns:samlp="urn:oasis.."
xmlns:saml="urn:oasis.."><saml:Assertion xmlns:samlp="urn:oasis.."
xmlns:saml="urn:oasis.." ID="..." IssueInstant="..."
Version="2.0">...</saml:Assertion></dummy>

3) This is then passed to deserialization to create the DOM representation.

Now, what happens in the deserialization is that the inner namespace
declarations get added as AttrImpl objects instead of AttrNSImpl (this
only happens to the two xmlns attributes, I suspect because they are
already defined in the dummy element?) - the other attributes from the
saml:Assertion element get added correctly as AttrNSImpl objects.
(the document is namespace aware).

Now, before digest computation c14n is called on this object.
(I'm using http://www.w3.org/2001/10/xml-exc-c14n#) -
However Canonicalizer20010315Excl now stumbles over the two attributes
from above, and does _not_ recognize them as namespace declarations,
because in handleAttributesSubtree() (Line 187)
attribute.getNamespaceURI() will obviously return null on these two
attributes, with the result that the NS attributes will get added twice,
leading to broken XML and a wrong digest computation.

This is what the contents look like before digest computation (note the
redundant xmlns:saml attribute):

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="..." IssueInstant="..." Version="2.0"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

If I debug into it, and suppress adding the NS attributes to the dummy
element in the AbstractSerializer, then everything works perfectly.

I suspect a bug in the XML parser/deserialization, but I'm really lost
here. Does anyone have a hint on where to look next? Or is this a known
issue?

Thanks and best greetings
Lars


Mime
View raw message