Chaining SessionInitiators

[Cantor, Scott]

On 2/17/12 10:37 AM, "Christopher Bland" <chris at fdu.edu> wrote:
>    
>    Your response challenges my understanding of what I'm trying to
>    accomplish so let me ask you this.  If I have a single SP that I
>    associate with 3 IDPs is it possible to configure a DS to
>    automatically validate a previous session without prompting the
>    user.

The DS doesn't do sessions. If you mean can it record previous choices,
yes. We believe it is the wrong UI to dispatch automatically on a cookie,
because that makes it impossible to correct errors/mistakes without
dumping cookies, but there are options in most DS software to auto-select
an IdP if a cookie is set. But that has nothing to do with "active
sessions".

>  For what I am intending, I am going to set a default IDP for
>    each application on the SP but want sessions from all IDPs to work.

If you mean, can the DS tell that you're logged into one app when a second
app sends the user to it, generally not. It depends on domains and cookies
and where things are running, and even with that, the DS can't tell
anything about the session. It isn't the SP, it doesn't know who the user
is or have access to the user's identity or information from the session.

> 
>    Also is there any way to specify a session hierarchy in case a user
>    happens to have active sessions with more than one of the 3 IDPs?

"Active" sessions are only visible to the applications that they belong to
by definition, so there is nothing you can do when you're not part of that
application.

The closest would be using the idpHistory option to track IdPs used by a
client, rely on the order to determine the most recent, and somehow make
the cookie visible to every involved resource, and make some assumptions.
And then there's isPassive and using that to probe for sessions at an IdP,
but that makes error handling very complex.

I think you have to inject some kind of proxy element into this mix to get
anything close to what you want. If all the traffic flows through a
gateway IdP, then it brokers the sessions and knows that you're logged
into a given backend IdP and when an SP requests login from it, the
gateway IdP/SP combo can say "you're logged in here now, so reuse it".

Or maybe you can simulate that using some kind of shared domain and using
custom cookies to set signals that you're actively logged into something,
though I suspect that will end up going stale because of logout
impossibilities. That has been attempted before in the OpenID community to
get consensus on using a shared domain to track OpenID providers for a
user. It's a privacy mess, but within an enterprise scenario, not so much.

-- Scott