The problem with IDP initiated SSO

[Christopher Bongaarts]

On 12/23/2014 11:13 AM, federator wrote:
> 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.

Step 1 is where there is no interoperability - those links to IdP 
functions are proprietary to the IdP implementation.

> 2.  A user visits the IdP's web page and select one of the SP link to
> access.

Step 2 introduces a scalability problem (we have about 800 local SPs on 
our test IdP and 400 in production, and that's not counting the several 
hundred SPs in the InCommon federation...)

> 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

Also has the downside of preventing deep links requiring authentication 
into an SP.

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

Doing SSL client auth with the SP (if that's what you're talking about 
here) sort of makes the whole SAML authentication redundant (and is not 
going to be very scalable unless all your SPs are under the same 
adminstrative umbrella).

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

The idea behind XSRF is that a malicious site can essentially make the 
user send an authenticated request to a target site with data controlled 
by the attacker.  Tying cookies to URLs doesn't matter, as the attacker 
doesn't ever use them directly; everything about the forged request is 
legitimate except the contents of the request itself.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%