OpenSAML user discussion

[Brent Putman <>]

Brent Putman wrote:
> If the Decrypter.decryptData is used(), it unmarshalls an XMLObject
> around the DOM DocumentFragment returned by Decrypter.decryptToDOM().  
> And the unmarshaller there should be (incorrectly) setting the IDness on
> the DOM Attribute and therefore the Apache xml-sec IDResolver should be
> able to resolve it.  So I suspect there's a deeper bug.  I suspect
> perhaps a DOM node adoption  issue - maybe the DOM nodes aren't being
> unified into the same Document properly somewhere.   I'll have to
> investigate some more, this might be a tricky one to debug.
>
>
>   


So I managed to nail this down.  In hindsight it's pretty obvious.  This
was not specific to the SAML object provider classes, but rather an
issue with the XMLTooling Decrypter.  The decryptDataToList() and
decryptData() convenience methods unmarshall the child Element Nodes of
the decrypted DocumentFragment and return XMLObjects.  The unmarshaller
of an XMLObject provider is supposed to set the DOM Level 2 IDness on
ID-typed attributes in case the DOM wasn't schema validated, etc, and
this in fact was working correctly, i.e. the ID-typed Attr Node in the
underlying cached DOM returns true for isId(). 

The problem, however, was that the Element underlying the decrypted and
returned XMLObject was not a part of the tree of nodes rooted at the
owning Document's document element.  The Apache XML Security IdResolver
uses Document.getElementById() to resolve ID attributes.  This fails if
the ID attribute's owning Element is not in the document element tree
(in hindsight pretty obvious, I suppose).

For most use cases this is probably fine. In XMLObject land you don't
necessarily care about the relationship of the underlying cached DOM
elements, and if you do, you can always drop the DOM and remarshall,
etc.  However, this won't work for signatures, b/c you can't drop the
DOM on the Signature object (because it works differently than standard
object providers).

We discussed and what we came up was to provide the option to have the
Element underlying the decrypted and returned XMLObject be the document
element of a new Document.  This allows DOM-level ID resolution to
function properly for cases where the decrypted object is going to be
signature verified in a standalone manner.

There's extensive docs in the XMLTooling decrypter class, but the
executive summary is the new 2-arg method variant:

decrypter.(encryptedData, true)

The arg of 'true' causes the returned object's underlying Element to be
the root element of a new DOM Document.  Signature verification on the
decrypted object should then work correctly since DOM-level ID
resolution now works.  Note that if the decrypted signature element has
Reference with a same-document URI reference that points outside of the
decrypted object,  that doesn't work.   That case would be pretty messy
and crazy in our XMLObject world - if it's even possible, you'd have to
find a way to unify all the different DOM trees (probably involving some
convoluted sequence of DOM dropping + marshalling/unmarshalling and/or
black magic).  In that case one should probably just use the
decryptDataToDom() method instead and manually process the resultant DOM
DocumentFragment.

So, Enrique, if you want, pull down the latest code, and make sure it
works for you.  I also have a new unit test out there for this as well,
which seems to work OK.

Thanks,
Brent