OpenSAML user discussion

[Brent Putman <>]

Scott Cantor wrote:
> When unmarshalling from a file, the library is (possibly incorrectly)
> treating the attribute as an ID, either manually or because it's validating
> with the SAML 1.1 schema set. That results in a valid signature (but
> shouldn't if this is actually SAML 1.0).
>   

Yes, the unmarshaller is still incorrectly setting the IDness even for
MinorVersion = 0.    Somewhere I had on my todo list to fix that.  I'll
take care of it.  But that doesn't explain the problem.  I believe it
still should have been (incorrectly) working (i.e. resolving the ID
attribute).  My guess is that it would still be broken for SAML 1.1. 
I'll try and test.


> Decryption is perhaps returning a DOM directly, and there is no way for the
> IDness to be established (even incorrectly) there unless one is validating
> the DOM afterward, or by unmarshalling an XMLObject tree around the DOM,
> which would enable SAML-specific logic to kick in and set IDness that way.
>   

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.