supporting IdP-initiated SSO only

[Cantor, Scott]

On 3/16/13 3:59 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>Oh, okay, you're right. Maybe I should have sent the following
>question to the saml-dev list:
>
>Why does the SAML2 Metadata spec require at least one
>SingleSignOnService element in every IDPSSODescriptor? AFAIK, an IdP
>that supports SAML2 Web Browser SSO is NOT REQUIRED to accept
>AuthnRequests.

An IdP is in fact required to do that, as far as I recall, if it wants to
be conformant, but conformance is an implementer concept, not a deployer
one. And metadata is about deployments. So I would agree that it's a
mistake. Regardless, the change you want is impossible, so it doesn't
matter what I would or wouldn't do if I was doing it today.

As to your use case, most of the time, such an SP is already supporting
SAML 1 via Shibboleth protocol and the whole problem is with getting 2.0
deployed, so it's a trivial matter to add the protocol string without
adding a new endpoint. Or should be. It's not ideal that one has to, in
InCommon's case, add an Artifact endpoint to get the string added, but it
works.

In the case where something like SAML 1 isn't there already, it *is*
entirely about discovery, as Ian said. Alternatively, I would do what Ian
suggested and simply define a binding vaue to signify whatever you want to
signify. It won't get used by anything, so nothing will break. The
Shibboleth SP will ignore SAML 2 usage for any IdP without a compatible
binding, just like if it was configured to Redirect but the IdP only did
POST.

-- Scott