IDP Initialized SSO - IdPUnsolicitedSSO

[Cantor, Scott]

On 12/12/12 10:36 AM, "Zmuda, Matthew R" <Matthew.R.Zmuda at td.com> wrote:

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

I can't get into understanding the details of highly specialized
deployments that aren't actually SAML, not in the half hour a day I spend
supporting people. If you're saying that the second application isn't
really running SAML software, doesn't support the full profile, etc., then
yes, pushing the response is one way to limit what it has to support. But
not meaningfully. Requests are the easy part.

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

It has nothing to do with App1. SAML Browser SSO is between an IdP and an
SP, it doesn't involve multiple apps. The way you should do it is send the
user to App2, have it detect that authentication is needed, generate a
SAML request to the IdP and so forth. That doesn't involve App1, and the
user doesn't need to even visit App1 at all.

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

I don't really see the difference from the point of view of the IdP and
App2. I don't see what App1 has to do with any of it.

Again, if you're trying to implement SAML SSO, there is nothing gained
from requiring unsolicited SSO except saving a relatively small amount of
code on the SP side.

-- Scott