On Wed, Nov 29, 2017 at 1:08 PM, David Hawes <[email protected]> wrote: > On 22 November 2017 at 12:28, Fridolin Zurlinden <[email protected]> > wrote: > > Hi there, we use the CAS server and the mod_auth_cas Client (as module of > > Apache webserver) on our platform to authenticate and authorize users. > > > > > > > > We have 126 services installed and perform around 200000 logins per day. > > > > For failover and availability reasons our services are deployed > redundant on > > multiple hosts. > > > > > > > > Under these circumstances, it would be nice to have a shared session > store > > on the client side between these hosts. > > > > For now, we use the CASCookiePath directive, which points to a directory > on > > the host. > > > > > > > > Our attempts to use a file share or synchronizing the directories between > > the hosts failed due to raise conditions. > > mod_auth_cas uses flock(), which does not lock files over NFS. I would > definitely expect problems. It may be possible to use fcntl() to lock > files over NFS, but I'd have to do more analysis to know for sure. > > > Do you have any advice for us how to store the sessions with clients on > > multiple hosts? > > If you are using an LB with session affinity (stickiness), you may > want to turn it on. This would not share sessions between hosts, but > you'd get the benefit of not having to do CAS authentication each time > a client goes to a different host. If you're able to do this, I'd bet > you already have it on. > > You can also play around with fcntl() to see if locking works > correctly over NFS. > > > Best case would be to store the sessions in a redis like backend. > > > > Is there any such implementation available or planned? > > There are no plans that I'm aware of, but I agree that would be the best > case.
One alternative route might be to employ hazelcast for both distributed ticket registry and session replication amongst your collection of CAS nodes. The major benefit from this approach: apps using CAS integrations other than mod_auth_cas will also benefit. A highly available CAS environment needs to do the following, and hazelcast facilitates these goals. - Replicate user login information - Replicate tickets - Ensure all tickets (TGTs, service, and proxy tickets) are unique across JVM Check out the docs appropriate for your version on these https://apereo.github.io/cas/5.0.x/installation/Webflow-Customization-Sessions.html#server-side-sessions <https://apereo.github.io/cas/4.2.x/installation/Hazelcast-Ticket-Registry.html> https://apereo.github.io/cas/5.1.x/installation/Hazelcast-Ticket-Registry.html#configuration <https://apereo.github.io/cas/4.2.x/installation/Hazelcast-Ticket-Registry.html> Steve -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CANSvah5hKfajs1Ft_V3%3DAGWiZcUs%2BCN6JfMrTq56dV6VduMWEg%40mail.gmail.com.
