OpenSAML user discussion

[Jaime Pérez Crespo <>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

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.

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 have no problems to set  
it, but it's completely painful to retrieve the manually-crafted  
Advice from an existing, custom SAMLAssertion. To do that, I'm getting  
the owner document of the assertion with:

        Document document = assertion.toDOM().getOwnerDocument();

Now, I just search for any Advice elements inside the assertion with  
something like:

        NodeList advices = document.getElementsByTag("Advice");

The problem is that this simple code does not work for me, although  
the advices are there. Now the point is that if I do:

        assertion.toString();

just between the two lines of code before, it works like a charm. And  
what's even more strange, if the assertion is signed, there's no  
problem at all, everything works fine from the beginning, no need to  
call toString().

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. 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.

I've tried doing the same fix plantRoot() does in my code, so I first  
do the plantRoot() stuff, and then i call getElementsByTag() on the  
resulting document. That works fine, always.

My question is: is this a bug? Why the owner document gets broken  
sometimes? Why toSAML() is not calling plantRoot(), just as toString  
does? 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(). The  
mere idea of calling toString() on the SAMLObject to ensure the  
Document object is correctly mapped to the contents of the SAMLObject  
is absolutely crazy for me...

Regards,

- --
Jaime Pérez Crespo
Middleware Engineer
red.es / RedIRIS NREN

mail: 

xmpp: 

http://www.rediris.es





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhQ7HoACgkQ5f+rJs0i1iEqIgCghv0bBLKpr6g4kuC9nfittajD
qMoAnRCsiuaU1t1VaiMltNc4HLQJLIuo
=J8ck
-----END PGP SIGNATURE-----