OpenSAML user discussion

["Scott Cantor" <>]

> I just need to access the DOM to put contents into the Advice tag,
> without having any other child tags. That's what I was telling, our
> specs force to put Advices in this way:
> 
> <Advice>
>      textContent
> </Advice>
> 
> But maybe we should review our specs...

Yes, I'm sorry, but that isn't schema-valid. If you feed that into OpenSAML,
it will fail to parse it. Or should anyway. AdviceType is a complex type and
that's a simple content model.

> No, see above. Unfortunately we can't use setAdvice() to build the
> advices the way we want...

No, but as I said, that's by design since what you're doing isn't spec-legal
in SAML. Sorry...

> Well, I know OpenSAML1 does not support any other way to set advices
> manually, but I understand this is where toDOM() makes sense, no? I
> mean, at least you provide the "do it your way" method, which is
> toDOM() here...

No, that isn't what toDOM is for. It's used to obtain a DOM representation
of the object (note, NOT a document) for attachment to a document, or to
serialize it. It is not intended to give you the freedom to change the DOM.

> >> It's exactly the same use case as signing and
> >> validating signatures on an OpenSAML object. You can't sign() and then
> >> inmediately validate an object, which is absolutely crazy.
> >
> > You can't do that in most libraries. Try it with xmlsec alone. It
> > fails miserably.
> 
> I've never used xmlsec alone. Does it really behave like that?

Yes. I had to explicitly give up on trying to allow for validation
immediately after signing because the internal state of the Signature object
doesn't reflect the state of the DOM after signing.

> That's what I was talking about. Such kind of behaviours are absolutely
crazy
> for a user who does not know anything about the internals of the
> library (and since we are talking about libraries, users should never
> know about the internals...)

Welcome to the world of XML libraries.

> And now we are talking about signatures, I'll ask you another
> question: what's your recommended way of testing signatures? I mean,
> if you need to validate an object recently signed, what would you do
> to ensure validation will work?

Probably serialize it according to some strategy you need to use in your
application, and then reparse and validate it. What you're talking about
(validating immediately) is really not a normal use case. There's no reason
to do it, which is one reason why you tend not to find support for it.

> Yes, I understand that every SAML object can have a context, and that
> context will be "destroyed" if you root the Document to the current
> object. But think also about the opposite, what if you just got a new
> assertion, and you don't mind if it is part of a bigger document? I
> guess you can be sure the document will be rooted if you created the
> object yourself (not from DOM), because that way you're sure it's not
> part of a bigger document, but, what if you don't know and you don't
> even mind?

Sorry, I don't follow your point there. Let's leave it at this: the current
behavior is not only what I needed, but what I feel is the correct behavior.
At a minimum what you're asking for would be a new method. Quite possibly
something worth doing, but since the code is dead, I'm definitely not going
to be doing it.

> Probably I don't, as I'm not SAML or XML expert. But that's why I'm
> saying that OpenSAML makes assumptions about the knowledge the user
> has about the internals of SAML or XML.

That is the reality of any library that doesn't force a reparse at the drop
of a hat. Caching a DOM requires assumptions.

I'm sorry the docs are insufficient, but while you're right that better
documentation would have saved you time, it definitely doesn't save mine.
Documentation is a huge amount of work, and not a single person who has ever
complained about it has ever donated a single piece of programming
documentation back in return.

-- Scott