intermittent IDP failure

[Russell Beall]

I've been watching this thread without a whole lot to say because I have never experienced this problem.

However, we have already the settings in place that have been recommended to Steven, for instance, we have an 8 hour session stickiness window, and we use X-Forwarded-For and the ClientIPValve in Tomcat to make the actual Client IP address show up to the Shibboleth IdP app.  I'm surprised that if you have the loadbalancer IP showing up to the IdP but some other IP showing up to the SPs, that you haven't had problems with that security check.  We've had SPs fail when the IP at the IdP differs from the IP at the SP.

Anyway, I do have a question…  Has it ever been tested and found that the session clustering was ever actually working?

What happens if you use /etc/hosts to force your browser to one node and then switch /etc/hosts to another node and try to login to a different SP using PreviousSession from the other IdP node?  (You'd have to make sure you are actually using the other node because some browsers don't switch immediately.  Safari usually does.)

Has anyone checked the Terracotta logs to ensure that one node is active and one is passive?  If both are active, then you'd have a split-brain condition and no sharing of session data.

Regards,
Russ.


On Feb 1, 2013, at 8:05 AM, "Cantor, Scott" <cantor.2 at osu.edu>
 wrote:

> 180 is not enough for many users to get logged in, but sending you back to
> the IdP cold isn't going to cause this error. It physically can't, because
> that step would include the SAML request.
> 
> The only way this happens is if the login context is not replicated and
> you switch IdPs in the middle of the login process. Or the back button of
> course.