OpenSAML and Apache Santuario (xmlsec) 1.5.1

[Brent Putman]

On 4/13/12 4:37 PM, Brent Putman wrote:
>
> 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. 


I just did a simple test using the DOM API.  Turns out, attribute
ID-ness does not persist across adopting the Element into a new
Document. Or at least, Document getElementById does not work on the new
Document after adoption.  That's a bit surprising to me, I don't know if
that is a bug in Xerces or the intended behavior.

In OpenSAML Java, for historical reasons, our single-arg marshaller
method marshall(XMLObject) always unconditionally creates a new Document
and adopts the DOM tree into it.  So that would definitely explain what
you are seeing with the logging/debugging behavior.  Most of those
logging/printing utility methods just marshall unconditionally since
they need to operate on the DOM.  So, hopefully that solves the mystery
there! :-)

For various reasons, including the cost of adoption, I've often thought
that that unconditional new Document creation and adoption in the
marshallers was a bit sketchy.  I believe C+ OpenSAML doesn't
unconditionally do that, it first checks whether the XMLObject already
has a cached DOM.  On the other hand, there could be problems with not
doing it in some cases, such as when you want to make the cached tree
hierarchy consistent again (e.g. your case of wanted to replace
Encrypted* things with the corresponding decrypted instance).  It was
already on my todo list to look at this for OpenSAML v3.

Thanks,
Brent