OpenSAML user discussion

["Scott Cantor" <>]

> First of all, I know version 1 of the library is now deprecated in
> favour of version 2, but in eduGAIN we are still using it meanwhile we
> complete the migration to version 2.

It's not deprecated, it's unsupported for external use. That's a
significantly different meaning. That code is now your responsibility to
maintain if there's a security issue.

This is not a "typical" strategy for a project to take, but OpenSAML was
never meant as a supported external project in the past, and my Java
abilities and project commitments make it impossible for me to do anything
else.

> Now, the question: I'm having problems when trying to manage an
> assertion manually at DOM level. I need to set //Assertion/Advice
> elements on my own as the XPath used by OpenSAML1 to store advices
> doesn't fit our technical specifications.

I would say offhand that that isn't a good idea.

> I have no problems to set
> it, but it's completely painful to retrieve the manually-crafted
> Advice from an existing, custom SAMLAssertion.

You're supposed to call getAdvice. Why is that painful?

 To do that, I'm getting
> the owner document of the assertion with:
> 
>       Document document = assertion.toDOM().getOwnerDocument();

That isn't a supported approach.

> Now, I just search for any Advice elements inside the assertion with
> something like:
> 
>       NodeList advices = document.getElementsByTag("Advice");

First of all that's a DOM1 call, which is illegal here. Secondly, it would
return every nested Advice element, even one inside an assertion that's
itself nested inside the top one. I made that mistake numerous times.

Lastly, if the element in question is nested below the assertion, you can
call getElementsByTagNameNS on the *Element* interface, you don't have to
use the Document.

> Reviewing the SAMLObject.java code, it seems like toDOM() just returns
> the current Node stored in the root attribute of the object, which
> sometimes has an incorrect owner document.

That's false. It's not an "incorrect" document. The issue is that OpenSAML
doesn't guarantee you that the object itself will be *rooted* as the
document element because it can't. It has no idea what you plan to do with
the document, or what the object's relationship with that document is.

> More precisely, it seems
> like toString(), as well as other methods like toStream(), call
> internally a protected method of SAMLObject called 'plantRoot()'. That
> method seems to fix the owner document by putting the correct root
> Node (shouldn't the 'root' attribute already point to the real root?)
> as its child.

That's a side effect of using c14n to do the serialization, which happens to
require the object be rooted. As does signing.

> My question is: is this a bug? Why the owner document gets broken
> sometimes? Why toSAML() is not calling plantRoot(), just as toString
> does?

See above.

> Or maybe am I missing some detail? If this is not a bug, then
> the usage of the library is completely broken in my opinion, as
> someone calling toDOM() on a SAML object would expect *always* to have
> *exactly the same* contents in the SAMLObject itself and in the
> Document object retrieved by means of toDOM().getOwnerDocument().

No. The content of the object is fine. The problem is that the content of
the Document depends on the context of use.
 
-- Scott