supporting IdP-initiated SSO only

[Tom Scavo]

On Sat, Mar 16, 2013 at 1:59 PM, Ian Young <ian at iay.org.uk> wrote:
>
> On 16 Mar 2013, at 16:57, Tom Scavo <trscavo at gmail.com> wrote:
>
>> Suppose a Shib IdP supports SAML2 IdP-initiated SSO only. What does
>> its metadata look like?
>
> Kind of an interesting hypothetical.  Can you explain why a Shib IdP would choose to only support IdP-initiated SAML 2.0 SSO?

Well, as you know, the moment you add an IDPSSODescriptor with a
SingleSignOnService endpoint to a federation metadata aggregate, that
IdP will appear on discovery interfaces and SPs can/will start sending
AuthnRequests to it. OTOH, if the IDPSSODescriptor contained no
endpoints, SPs would not be able to send any AuthnRequests, but IdPs
would still be able to push unsolicited responses. This would give an
IdP a way to ease itself into a federation.

> That would mean it didn't support the SAML 2.0 Web Browser SSO Profile.  Unsolicited responses are only an optional part of that profile.

I don't think unsolicited responses are specified in the SAML 2.0 Web
Browser SSO Profile (which is why I sent to the question to this shib
list and not the saml-dev list).

>> Since an IDPSSODescriptor MUST include at least one
>> SingleSignOnService endpoint,
>
> This is related to the fact that the Web Browser SSO Profile in the SAML 2.0 specification involves the SP sending a request to the IdP.

Yes, that's right, which is exactly what I'm trying to avoid.

>> I'm not sure how to answer that
>> question. Seems the only option is to define a custom RoleDescriptor.
>
> If you define a custom RoleDescriptor, no SP will understand it.

That's true, and that's why I'm raising this question here. I didn't
realize until today that this use case (i.e., a Shib IdP that supports
SAML2 IdP-initiated SSO only) can not be encoded in a standard entity
descriptor. So the only way this will happen is if the Shib SP and the
Shib DS both support the use case.

Tom