Dec 9th, 2010, 02:54 AM
Question about Spring Security SEC-1528
I saw this in Jira - Spring Security SEC-1528 - HttpSession.setAttribute() must be called if the SecurityContext is modified during a request
Does this mean that with this change Spring Security will now work in a cluster if the session is replicated across the cluster? Any examples of how to get this to work?
Dec 9th, 2010, 08:29 AM
Luke may provide more details, but that specific bug was only for Spring Security 3.1.x which optimised (see SEC-1307) the test for determining if the Security Context needed updated. In general, with the proper setup Spring Security is expected to work in a clustered environment.
May 4th, 2011, 08:29 AM
Could you give me more details where I can get any example about the Spring Security setup to make it work in a clustered envorinment?
May 4th, 2011, 09:19 AM
Spring Security requires the same type of setup for a clustered environment that any application that uses session does. The setup will vary by the application server you use (i.e. Tomcat, WebSphere, etc), so you should consult your containers documentation. In general, you will want to look for configuring "session replication" in your application container. The other thing that varies based upon your environment is setting up "sticky sessions". This setup will vary based upon what you are using to perform load balancing (i.e. HA Proxy, Apache, F5, etc).
May 4th, 2011, 10:44 AM
Thanks for the quick reply!
And if I use the ConcurrentSession strategy.Do I have to implement a distributable SessionRegistry?
There is some posts that says that I will. Maybe I could be misunderstood.
I'm using the Spring Security 3.0.5.
May 4th, 2011, 01:00 PM
Yes...I overlooked that. In general, you will not be able to use any in memory implementations in a clustered environment. This should not differ from what should be done in any production environment.
May 4th, 2011, 01:30 PM
Congratulations, Spring Security is very cool.