The problem with IDP initiated SSO

[federator]

On 12/23/14 12:52 PM, Cantor, Scott wrote:
> On 12/23/14, 5:13 PM, "federator" <wpadmin at identiainc.com> wrote:
>
>> 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.
> The set of SPs a Shibboleth IdP could support could be in the thousands.
> Even in the facile B2B space that commercial SAML limits itself to, there
> are companies with thousands of SPs. You can't just list them all.
>
> You've also turned the IdP into a portal. Users want to access services,
> they don't just conveniently go to pages you want them to use to get to
> completely different things they really do want to use. The usability of
> that approach is just zero.

Despite of having all the SPs info, the front page doesn't have to 
display all the SPs.  You may choose to have the IdP or portal display 
only a subset of the SPs which user may be allowed to access, upon 
successful authentication with the IdP and the domain user is in (e.g. 
domain info embedded in user's cert).  So the usability of this approach 
is to keep control of which SP user can gain access to.
>
> It also precludes deep linking, and there's a word for federated
> applications that don't support deep linking: broken. Breaking the
> addressability property of thw web is about as cardinal a sin as you can
> commit.

We are all sinful in front of God :).  Anyhow, I see this is just an 
implementation issue.
>> This approach may be a little awkward since the user always has to go
>> back to IdP when logging in to any web site.
> It's not just a little awkward, it's extremely awkward.
>
>> 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).
> I don't know who's telling you that, but that isn't true. There are
> academic papers noting the inherent vulnerabilities in unsolicited
> response handling in SSO protocols.

I would be very interested in seeing the papers.  Could you provide some 
references?
>> 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.
> Cookies are only meaningfully bound to domains, not URLs. Beyond that, I'm
> not sure what you're asking. I've had people literally file bugs against
> the SP because it's vulnerable to XSRF, and there's not much I can say
> other than I want to fix it, but the only fix is to prohibit uncorrelated
> responses, which is unfortunately a very common hack to cirumvent the need
> for discovery.
>
> The most common example XSRF attack scenario is the bank scenario I
> mentioned, which generalizes to any scenario in which getting somebody
> else to act in the security context of an attacker is a benefit to the
> attacker.
>
> -- Scott
I guess the initial question was whether IdP initiated SSO would have a 
higher vulnerability than SP-initiated SSO.  Apparently if the 
vulnerability exists, it could happened to SP-initiated SSO as well, or 
both have the same possibility of getting attacked, or not?
>