Is it possible to distribute "loginContexts" (which is like a short-lived session, so some information from the first request will be still available within the next request, till the login succeeds - the cookie "_idp_authn_lc_key" ) within the cluster??
We are using the Redis to store the session information by overriding the Shibboleth's StorageService. Many forum answers say, it is possible only with sticky sessions and the loginContext stored local-only.
Is there anyway to save loginContexts on cluster without using the sticky sessions. Currently we are getting "No login context available" error one of the tomcat.
Our request flow is - Akamai - Apache Servers (Cluster) - Tomcat Servers(cluster)
Note: _idp_session cookie(which is a long-lived session) works fine,
That's right. The login context is stored via an API that isn't exportable to solutions such as EHCache, memcached or Redis. You need to use sticky sessions.
The session that the user gets is available, and that is generally what gets shared amongst the cluster nodes.
... if your load balancer doesn't support sticky sessions, you may be able to get some mileage (very untested) by using a reverse proxy layer in front of your IdP that looks at the login context session cookie, determines which node it was for/from and forward it there. I imagine something like HAProxy or Nginx could do that. Instead of trying to parse the login context session cookie, you might instead do a cookie insert of your own for your second-tier sticky load-balancer.
Finally, you might also just consider doing a high-availability cluster, and do Active/Passive with a floating IP.
Glad to hear that you are using REDIS for this, as I need to revisit how I'm going to cluster my IdP for logout.