The problem with IDP initiated SSO

[Cantor, Scott]

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.

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.

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

The only attack surface involved with SP initiated SSO that I've ever 
heard of involves the use of signed requests, and it's merely a denial of 
service vector, one among hundreds that any web site is vulnerable to.

Using TLS *is* a fix for this in a very theoretical technical sense, but 
it's not a deployable fix. The only deployable ones involve cookies 
correlated to requests so that responses aren't accepted without prior 
initiation. That said, I have not done the research to figure out how to 
implement this. It's not as simple as just using cookies, there also has 
to be secret information mixed in known only to the SP.

>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