login page state

[Tom Poage]

With deprecation/removal of the login ticket ("lt") from the CAS login page (around 4.2.6 or so), it seems login is now "stateless", in that one can now submit the login form to a different cluster server than which generated the login page.

Before we ask to change (remove) our load balancer TLS sticky settings, can someone confirm this is the case/intent? Same for CAS 5?

Thanks!
Tom.

[Misagh Moayyed]

Yes and yes.  Test before switching. 

[David Curry]

So just to confirm... does that mean that this paragraph:

There is a further consideration for active/active deployments: session affinity. Session affinity is a feature of most load balancer equipment where the device performs state management for incoming requests and routes a client to the same node for subsequent requests for a period of time. This feature is recommended and required to avoid servlet container session replication, which is generally more complex and less reliable. The core of this requirement is that servlet container session storage is used to maintain state for the CAS login and logout Webflows. While it is possible to achieve truly stateless active/active deployments by plugging in client-based state management components, such configurations at present have not been proven and are not recommended without careful planning and testing.

from https://apereo.github.io/cas/development/planning/High-Availability-Guide.html is no longer applicable and should be removed (or turned into a paragraph that explicitly states you don't need session affinity any more)?

Thanks,

--Dave

[Misagh Moayyed]

So just to confirm... does that mean that this paragraph:

 

There is a further consideration for active/active deployments: session affinity. Session affinity is a feature of most load balancer equipment where the device performs state management for incoming requests and routes a client to the same node for subsequent requests for a period of time. This feature is recommended and required to avoid servlet container session replication, which is generally more complex and less reliable. The core of this requirement is that servlet container session storage is used to maintain state for the CAS login and logout Webflows. While it is possible to achieve truly stateless active/active deployments by plugging in client-based state management components, such configurations at present have not been proven and are not recommended without careful planning and testing.

 

from https://apereo.github.io/cas/development/planning/High-Availability-Guide.html is no longer applicable and should be removed (or turned into a paragraph that explicitly states you don't need session affinity any more)?

 

Yes, the paragraph should definitely be changed. Note that you can still configure CAS to use server-backed sessions, and certain features of CAS do require that behavior anyway.

[Tom Poage]

And this tested out just fine with a short load test: several iterations of request login page from server A, POST to server B, validate on server C, for various values of A, B and C.

Tom.