Chaining SessionInitiators

[Cantor, Scott]

On 2/17/12 9:18 AM, "Christopher Bland" <chris at fdu.edu> wrote:
>    
>    I have what is probably a beginner question about SP
>    SessionInitators.  Previously I have only dealt with SPs using a
>    single IDP.  I have always provided Metadata for development and
>    production IDPs but have not simultaneously used sessions from
>    both.  It seems that all I have to do is within a
>    <SessionInitiator type="Chaining"> tag have a series of
>    individual SessionInitiator tags specifying each IDP available for
>    authentication.

No. Chaining the plugins is for connecting protocol initiators (SAML2,
Shib, etc.) with discovery initiators (SAMLDS) that don't have an assumed
entityID. You can't just have more than one protocol initiator with
different entityIDs, only the first one will matter. The protocol plugins
look for an entityID to use and if missing, fall through to the later
plugins. The discovery plugins run without an entityID set, and dispatch
to a page that eventually returns the client to the original location with
an entityID set, at which point the protocol plugins can run.

>    What's unclear to me is the process of associating a user with an
>    IDP.  I get that IDPs are processed in series

They aren't. Or rather they are, but the later ones never get used unless
the earlier ones can't dispatch because of metadata issues (lack of
support for a given protocol).

> but does the
>    SessionInitiator only check for existing session and sends users to
>    the default or DS session initiator if it doesn't find previous
>    session?

No. The DS session initiator is what gets used when no prior initiator has
access to an entityID to run with.

Multiple IDPs means doing discovery, or it means URL trickery to hardwire
the entityID based on the resource. It is not based on the user or by
chaining them together like that. There's no conditional logic available
to decide which one to use.

-- Scott