IDP Initialized SSO - IdPUnsolicitedSSO

[Zmuda, Matthew R]

I may have miscommunicated a detail.

Today App1 and App2 use separate IDPs, that is they authenticate users in different ways using different applications.
I am working on the IDP that authenticates users for App1. This process does not use Shibboleth, its simply an authentication application that redirects authenticated users to an application.

After a user uses the IDP to authenticate and access App1 I want to allow the user to SSO via SAML token to App2, which currently has no ties to App1 whatsoever.
I do not want to enable App2 to use the IDP to authenicate users directly.
My original thought behind using IDP initialzied SSO is that since we already have a user who has logged into App1, I should be able to simply send them to App2 through our IDP using SAML token.
So App1 would send request to IDP for SSO to App2. IDP would generate the SAML token (AuthNResponse) and redirect to App2 who will accept the user.
This is a 1 way SSO, user will not be able to go back to App1.

I did mention in my initial post that our IDP is currently using Shibboleth, but this is simply to authenticate a user after getting a AuthN Request from another vender and sending AuthNResponse back.
In that case we are using standard SP/IDP flow to authenicate users. This of couse is different from what I want to accomplish with the flow I described above.

Clear as mud? :)

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, December 12, 2012 10:07 AM
To: Shib Users
Subject: Re: IDP Initialized SSO - IdPUnsolicitedSSO

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


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, please go to www.td.com/legal for instructions.
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. Si reçu par erreur, prière d'aller au www.td.com/francais/avis_juridique pour des instructions.