The problem with IDP initiated SSO

[federator]

I am new to Shibboleth, so I guess I missed all the fun with SAML 1.0.  
Anyhow, the initial IdP request message could be just a HTTP Get from 
user's browser, so I am not sure why you need to standardize the request 
message, unless I am missing something. Considering the following workflow:

1.  The IdP contains a Web front end listing all the SPs which the IdP 
supports.  Please note these links are not the URL to SP's but some IdP 
functions to verify the user authentication status.
2.  A user visits the IdP's web page and select one of the SP link to 
access.
3.  If the user hasn't already logged in to IdP, the IdP prompts the 
user for credentials.  Upon authentication, the IdP redirects the user 
to the SP of user's choice, along with the standard SAML response message.
4.  On the SP site, the SP checks the SAML assertion message and grants 
or denies user access.
5.  When the user needs to log in to a second SP, he or she needs to go 
back to the IdP page and selects the second SP link to access. At this 
point, the IdP recognizes the user has already authenticated, and 
redirects the user to the second SP directly, without prompting the user 
for credentials.

This approach may be a little awkward since the user always has to go 
back to IdP when logging in to any web site.  Since IdP always has to 
maintain SP's metadata, it has to keep track of all the SPs anyway.  I 
was told that this approach could minimize the attack surface compared 
to SP-initiated SSO, since I can easily implement 2-way SSL with both 
IdP and SP (some people just want triple layer security).

XSRF shouldn't be a big concern since most modern browsers and web 
applications tie cookies with distinct URLs.  If this is not the case, I 
would love to hear a concrete use case/example.

Thanks!

Nick
On 12/23/14 11:34 AM, Cantor, Scott wrote:
> On 12/23/14, 4:17 PM, "federator" <wpadmin at identiainc.com> wrote:
>
>> I assume the term "interoperability" refers to SSO.  If that the case,
>> as long as all SP's accept the same standard SAML response format,
>> interoperability shouldn't be an issue.
> Except for the first message to the IdP. Try defining that one
> interoperably. There is no such thing as IdP initiated SSO, that's the
> point. There is always a request message. The term "IdP initiated SSO"
> describes a profile in which the request message is undefined and the
> response is standardized. That was how SAML 1.1 worked. You can ask
> anybody that's been part of this community since before SAML 2.0 how much
> fun that all was.
>
>> XSRF can occur anyhow when cookies are used for maintaining sessions.
>> Better to use HTTPS for prevention...
> There is no channel binding in HTTPS with browsers, so you can't, not
> unless you use client certificates that are being bound to the session by
> the RP. Not even certificate authentication to the IdP is sufficient.
>
> The use of cookies can prevent the specific form of XSRF that the SAML
> flow is vulnerable to, though not others. But only if IdP initiated SSO is
> explicitly prohibited by the SP.
>
> -- Scott
>