supporting IdP-initiated SSO only

[Tom Scavo]

On Sun, Mar 17, 2013 at 3:03 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 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.

Okay, thanks for confirming my suspicions.

> 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.

In any case, I think I'll send a note to saml-dev...

> 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.

Understood. The latter can (and will be) fixed but it's not a high
priority since there's a workaround as you say.

> 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.

Yeah, that's an option, I suppose.

> 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.

But will the DS?

Tom