RE: [saml-dev] SAML error responses & security

["Scott Cantor" <cantor.2@osu.edu>]

> * Web SSO Profile (SAMLProf, 519/20):

If you don't send a response, the user is now trapped at the IdP and if I
were the SP and I was expecting to get the user back, I'd be pissed off.
That's why it's a MUST. It's not testable, this is a front-channel protocol.
Nobody can guarantee a response will work or that the user will get back,
but I can't think of too many reasons for not doing it offhand. If
somebody's chewing cycles and you don't want to let them, just don't sign
the message.

> "If the identity provider cannot or will not satisfy the request, it MUST
> respond with a
> <Response> message containing an appropriate error status code or codes."

Note that "appropriate" means what the IdP is willing to reveal, which may
be nothing.

> * SLO profile (SAMLProf, 1256-59)

SLO can't work at all if people don't fulfill their protocol obligations. It
probably barely works as it is. Again, I'm not sure why it would be a
"security" issue to not minimally respond, but it's untestable for
front-channel logout anyway.

> * Redirect Binding (SAMLBind, 682/83)

This is orthogonal, the binding is talking about how you communicate errors,
not whether you have to. And you can't signal a SAML error to the browser
using a 500, that should be fairly clear.

> Now there may be situations where it seems favorable not to respond for
> security reasons.

Such as?

> Am I missing something or would not responding be a violation of the spec
> in many cases?

To the spirit certainly. If I send a passive AuthnRequest, it's pretty bad
form not to respond. As the protocols get richer, people have to follow the
rules or you can't hope to build applications that work well because the
user will just get errors, be trapped, and never come back.

-- Scott