OpenSAML and Apache Santuario (xmlsec) 1.5.1

[Brent Putman]

On 4/13/12 7:34 AM, Stephanie Stroka wrote:
>
>
> First of all: unmarshalling non encrypted messages seems to work fine,
> except when the unmarshalled msg is marshalled again for
> logging/debugging purposes: This causes the Id to be lost.

Hmm, I'm not sure about the re-marshalling case, I would think that the
DOM ID-ness would be preserved there. 

>
> The second problem may be caused by using
> org.opensaml.saml2.encryption.Decrypter    to decrypt an
> org.opensaml.xml.XMLObject:


So, if you are doing decryption, and trying to verify the signature on
the decrypted thing (e.g. Assertion), the stuff from the Decrypter
Javadocs I sent later yesterday is absolutely relevant.  The underlying
DOM of the decrypted XMLObject is, by default, not a part of the tree of
Nodes of its owning Document, and so Document getElementById will
definitely fail.  To make it work, you must set the rootInNewDocument
property of the Decrypter to 'true'.  This causes the underlying  cached
DOM of the decrypted XMLObject to be the root Element of the owning
Document.  Note this will be a new Document, not the Document that owned
the original encrypted thing. For example, when you decrypte an
EncryptedAssertion, the resulting Assertion's Document will *not* be the
same as the Document which owned the original EncryptedAssertion and
Response.

I see in your later message that the code is (if I read correctly)
attempting to decrypt the Assertion and then replace the
EncryptedAssertion with that Assertion as a child of the Response.  In
terms of the XMLObjects themselves, that's fine.  As far as the DOM
level goes, though, be aware that that is not going to change the
underlying DOM structures and in particular their various parent-child
relationships.  If you verify the Assertion signature relatively
immediately after decryption (with rootInNewDocument == true) then that
probably won't matter much.  But just be aware of what is and what isn't
happening at the DOM level there.