OpenSAML user discussion

[Scott Cantor <>]

> Hmm, indeed the SAML SOAP binding says
> 
>   A SAML responder MUST NOT require any headers for the SOAP message.
> 
> but this seems kinda fuzzy; obviously a responder might have requirements
> on a request that it fit into some general messaging scheme in order to be
> able to give it a proper response, eg security or routing or whatever;
> and meeting those requirements might involve SOAP headers just as they
> might involve wrapping in SSL, etc.  Seems inappropriate for the SAML spec
> to declare that such schemes simply can't be used with SAML/SOAP.  Seems
> like something to clarify in 2.0.

Yes, I had been thinking along those lines, but didn't say so. The original
intent was largely to minimize SOAP as a source of interop problems, and
there's some merit in that, but it also leaves undefined how authentication
might be done while still requiring it be done somehow.

> Hmm, hmm, I guess it's the case that neither SOAP 1.1 nor 1.2 say anything
> about sessions.  So I guess out in the world people do sessions with SOAP
> however they feel like it.  Also the SAML SOAP binding says nothing about
> sessions.

No, but it requires authentication, and there are obviously ways of doing
authentication on a session-oriented basis as an optimization that might
take place above TCP, as in the case of a cookie, and it's probably not a
good thing to preclude them.

But I would argue that there is no other reasoning for allowing such a
header, including anything relating to SOAP value-add. The binding as it
stands specifically precludes such things so that implementing the SOAP
binding does not require implementing SOAP with X/Y/Z extension for reliable
messaging or what not.

That should be a separate binding from an interop standpoint, though maybe
one that will get defined someday.

This would have been so much easier without SOAP...

-- Scott