stateless IdP clustering with vs without SSO patch

[Cantor, Scott]

> A user logs into site on sp1 and is planning to be online for at least 8
> hours. By luck of the draw, first authentication is against idp1. For
> the next four hours, there is no interaction with the IDPs.

Normally there's more than one SP, though, so I'm not sure how your assumptions hold. The SP's session has really nothing to do with the matters of IdP session behavior, because the user is accessing SPs on and off all the time.

> At the four
> hour mark, the session expires so sp1 checks in with idp-lb - if it gets
> idp1 again, all is well for another 4 hours. If it gets idp2 this time,
> idp2 refers user to the authentication mechanism which (for Stanford at
> least) uses an SSO cookie and so re-authenticates the user transparently
> and then idp2 starts a new 8 hour session with sp1.

If you have a separate SSO system, then you're really in a different situation than OSU. At that point, the IdP's session is probably irrelevan except for logout, optimization, or complex custom login handler behavior that you must be trying to avoid in the first place by asking this question.

> Bottom line: user will have to re-authenticate at least once every 8
> hours and at most twice every 8 hours. In either case, the user doesn't
> actually do anything (it's handled by the cookie) but will experience a
> small delay while the authentication takes place.
> 
> Sooo...is my bottom line there on point?

I think the bottom line here is that you have a separate SSO system. In that case, you need session afinity for the Shibboleth login sequence each time, but not much else. All I did was build a cookie mechanism to avoid the need for a separate SSO system.

-- Scott