OpenSAML user discussion

["Enrique Rodriguez" <>]

On 4/6/07, Brent Putman 
<>
 wrote:
> 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.

This is what I'm currently seeing, that it is still broken for SAML
1.1.  I just updated my application and tests to use SAML 1.1 tokens
and they still don't validate.  The error appears to be identical.

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

Thanks for the time and effort, guys.  I've learned a few things, too.

Enrique