Passively check for session with multiple IdPs

33 views
Skip to first unread message

Donald Shaw

unread,
Nov 16, 2011, 1:03:25 AM11/16/11
to us...@shibboleth.net
Hi,

is it possible to quietly (probably "passively") check multiple IdPs to see if the user has a session with any of them, and only hassle the user with a login page (or Discover Service IdP-selection page) if they have no such sessions?

Thanks,
cheers,
Donald.

Peter Schober

unread,
Nov 16, 2011, 7:59:01 AM11/16/11
to us...@shibboleth.net
* Donald Shaw <donald...@gmail.com> [2011-11-16 07:03]:

isPassive is an attribute on an authentication request.
By default the software will only sent out one such authentication
request if configured via the webserver (or the portable
configuration), to either the default IdP or the IdP selected via
content settings.
So the only way to do this IMHO would be generate those authentication
requests yourself, programmatically (possibly with help of the session
initiator, where you would loop over all IdPs and keep sending the
user agent elsewhere).

Depending on latency and number of IdPs this probably won't go
unnoticed by the user and will most certainly not provide a good user
experience.

Also note that isPassive is of course SAML2 only, so if some of those
IdPs are still SAML1-only (I hear such things do exists) this wouldn't
work as indended.
-peter
--
To unsubscribe from this list send an email to users-un...@shibboleth.net

Donald Shaw

unread,
Nov 16, 2011, 9:35:26 AM11/16/11
to Shib Users
Yeah, I realise there may be latency, non-SAML2, and other such issues. Nevertheless, this is still something we want to investigate further (it may well end up interfering in the user experience less than other possible paths we might take).

How might an appropriate SessionInitiator for looping over 2 or more IdPs look?

Thanks for the feedback,
cheers,
Donald.

Peter Schober

unread,
Nov 16, 2011, 9:40:13 AM11/16/11
to us...@shibboleth.net
* Donald Shaw <donald...@gmail.com> [2011-11-16 15:35]:

> Yeah, I realise there may be latency, non-SAML2, and other such issues.
> Nevertheless, this is still something we want to investigate further (it
> may well end up interfering in the user experience less than other possible
> paths we might take).

Everyone agrees that discovery is painful but with the new
developments
https://wiki.shibboleth.net/confluence/display/EDS10/Embedded+Discovery+Service
or http://discojuice.org/ this seems to be a lot less intrusive or
error prone that trying all possible IdPs instead of just asking.

> How might an appropriate SessionInitiator for looping over 2 or more
> IdPs look?

When sending off the user agent off to all idps you know in turn
you'll need to keep track of those yourself (e.g. in a cookie or via
request parameters). The session initiators take the usual parameters
(see content settings in the wiki), e.g. entity=<entitityid-of-the-idp>

Cantor, Scott

unread,
Nov 16, 2011, 9:59:09 AM11/16/11
to us...@shibboleth.net
On 11/16/11 9:35 AM, "Donald Shaw" <donald...@gmail.com> wrote:
>
>How might an appropriate SessionInitiator for looping over 2 or more IdPs
>look?

There is none, you have to script the entire process via the lazy session
mechanism.

Some notes:

- the SP will now correctly return the client to the target resource if
you specify isPassive and it can't dispatch via a supporting initiator
(that handles the SAML 1 case)

- the SP will ignore the NoPassive error code and pass control back to the
target resource if the IdP returns that code

- any other error would terminate, so you'd have to handle errors with the
redirectErrors option

All of the features involved are poorly tested and probably buggy.

-- Scott

Reply all
Reply to author
Forward
0 new messages