<div dir="ltr"><div><div>Thanks for your response, I created <a href="https://issues.shibboleth.net/jira/browse/OSJ-154">https://issues.shibboleth.net/jira/browse/OSJ-154</a><br><br></div>Regards,<br></div> Detelin<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-04 19:46 GMT+02:00 Brent Putman <span dir="ltr"><<a href="mailto:putmanb@georgetown.edu" target="_blank">putmanb@georgetown.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>On 2/4/16 4:04 AM,
<a href="mailto:detelinyordanov@gmail.com" target="_blank">detelinyordanov@gmail.com</a> wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div> I have encountered an issue in Opensaml when marshalling
an existing SAML assertion into a newly created empty
Document. Apparently
AbstractXMLObjectMarshaller.marshall(assertion, Document) uses
Document.adoptNode() followed by Document.appendNode(..) but
neither of these preserve the IDness of the assertion and if
Document.getElementById(assertionId) is used on the resulting
document, it returns null.<br>
</div>
</div>
</blockquote>
<br></span>
This sounded familiar. I went and looked and someone encountered a
similar issue back in April 2012, discussed on this list.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>but then I noticed it is reproducible with Xerces as well
and I saw that Xerces folks do not consider this a bug in
Xerces DOM implementation - they argue that according to spec,
the adoptNode() is not required to preserve the ID attributes,
see <a href="https://issues.apache.org/jira/browse/XERCESJ-1022" target="_blank">XERCESJ-1022</a>
and respective discussion: <a href="https://mail-archives.apache.org/mod_mbox/xerces-j-users/200701.mbox/%3C20070125062002.01E3310FB003@herse.apache.org%3E" target="_blank">importNode()/adoptNode()
and getElementById()</a><br>
</div>
</div>
</blockquote>
<br></span>
Yep, I came across XERCESJ-1022 back in 2012. Sadly that seems to
be the official answer.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Does this mean that this is a bug in Opensaml/Xmltooling</div>
</div>
</blockquote>
<br></span>
Yes, I think it is a bug. I don't know why an issue was never
opened in 2012, but it wasn't and so we never really looked at
fixing this. Please open a bug against the v3 project (OSJ).<br>
<br>
As luck (or lack thereof) would have it, we literally just yesterday
released the last non-security patch release of the v2 project (JOST
in Jira), prior to its full EOL in July. So there wouldn't be any
plans to release it for v2. Unless there were some security
vulnerability aspect to this, but off-hand I don't see any. <br><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div>and Xmltooling node adoption code is required to ensure the
ID attributes are preserved when marshalling into a new
Document?<br>
</div>
</div>
</blockquote>
<br></span>
Aside from the fix in OpenSAML itself: Yes, after marshaling an
existing XMObject, you would reset the IDness the same way the
marshallers do it. For example, the AssertionMarshaller does this:<br>
<br>
<tt>domElement.setIdAttributeNS(null, Assertion.ID_ATTRIB_NAME,
true);</tt><br>
<br>
<br>
The fix in OpenSAML is likely to involve moving these
setIdAttributeNS(...) calls out of the marshallAttributes(...)
methods (which only get called when there is no existing DOM), and
into a new one like marshallAttributeIDNess(...). Then the latter
gets called in both the new DOM and existing DOM cases. Or
something like that. Doesn't look too bad to fix.<br>
</div>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div>