Strange behavior with SAMLSignatureProfileValidator

[Brent Putman]

On 5/9/17 5:18 AM, Massimiliano Masi wrote:
> The SAMLSignatureProfileValidator fails because the ID is not registered.

As an un-related comment: If you are doing the signing, why are you then
calling that signature profile validator?   It's really a bit
unnecessary.  You usually only call that when you are *receiving* a
signature to process, not when you are signing.  If you are doing just
for development/debugging purposes to validate, and don't plan to do
that in production code, that's fine.  But doing "for real" isn't really
necessary.

>         
>
>      
>
> The first idEleme is null, the second is not null. In order to make it
> working, I’ve to manually register the ID element in the toElement
> method (which is easy as it can be, see inline).

I suspect you are probably encountering this unfixed bug:

https://issues.shibboleth.net/jira/browse/OSJ-154

Summary: Unmarshalling sets the ID-ness of attributes properly, as does
marshalling an object created from scratch (no cached DOM).  But if the
object has a cached DOM Element, then the ID-ness is lost (really, it's
not re-applied) when the Element is adopted into a new Document.

So until this bug is fixed, probably in 3.4.0, you either have to 1) set
the ID-ness manually after you (re)marshall an XMLObject with an
already-cached DOM 2) Simply unmarshall a new XMLObject tree around the
marshalled DOM.

>
> Worthless to say that this code was working perfectly in OpenSAML
> 2.6.1. Any ideas?

Well, I'm not sure about the working in 2.6.1 part, the above issue was
present in v2 and never fixed there, as OSJ-154 and the linked email
thread indicates.  But maybe you are doing something slightly different
with the v3 code that is triggering it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170509/d6ced935/attachment.html>