stateless IdP clustering with vs without SSO patch

[Kevin Hall]

Hello All,

I started working on putting a pair of development IDPs behind a 
hardware load balancer and using Terracotta to share sessions, but after 
researching the shibboleth-users list decided to avoid TC and pursue a 
stateless setup instead. Was planning to use a version of the OSU SSO 
login handler linked from the Contributions page but wondering what the 
user experience would be like without it. I think it likely depends 
mostly on a given SP's session duration, eh? (And the number of IDPs 
behind the load balancer.)

I guess what I'm really looking for is a sanity check on my 
understanding of sessions and what would be the main drawback to rolling 
out a stateless LB setup without a custom SSO handler.

Example:

* idp-lb with members idp1 and idp2, each with a 8-hr session
* sp1 with a 4-hr session is pointed at idp-lb

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

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?

Thanks!

-Kevin