IDP Initialized SSO - IdPUnsolicitedSSO

[Cantor, Scott]

On 12/12/12 9:12 AM, "Zmuda, Matthew R" <Matthew.R.Zmuda at td.com> wrote:
>When you say "Better model: go the the second app, repeat usual flow,
>done."
>
>Would that be something like this:
>
>IDP --> App1 (User logs in as usual)
>App1 --> App2 (App1 sends user to App2 with some unique ID that
>symbolizes authenticated session)

No. There is nothing you send. You simply send the user to access that
app, same as the first one.

>Why do you say IdP initiated a bad thing? Seems that it would simplify
>this scenario to something like this:

It is a XSRF security problem that the SP eventually needs to block, but
more to the point it is not at all natural to users. It's designed for
portals that want to link users directly into applications, but users want
to simply access applications when they feel like it, not use links that
we would prefer them to use. It defeats deep linking and it causes
problems because users bookmark application pages and expect them to work.

It's one thing if it's an alternative path into a system, though it still
opens up XSRF issues, but often it's done so the SP doesn't have to
support making its own requests, and that's when the usability problems
occur.

>IDP --> App1 (User logs in as usual)
>App1 --> IDP (IdP generates AuthNResponse)
>IdP --> App2 (Sends AuthNResponse)
>App2 --> Establishes authenticated session and redirects user to target
>resource

I don't know why you're characterizing lines 1 and 3 as different, but
they would be the same. There is no "logs in as usual" other than a SAML
response issued to the SP. How that occurs is either in response to a
request from the SP or an unsolicited SSO link.

-- Scott