Load Balancing, Spring Security, ConcurrentSessionFilter

Question

I have a Spring 2.5.6/Flex application setup and running with Spring Security 2.0.4. Recently a load balancer (A Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html) was put into place and now I am getting cross domain errors. Basically the load balancer is firing off a request to myloadbalancer.abc.com and myrealserver1.abc.com is being returned as the domain name. Spring security is forwarding the request to the real server somehow. How can I get around this?

Also the ConcurrentSessionFilter is no longer working. The application is set up to disable concurrent logons, but this functionality stopped after the application was put behind the load balancer. I believe there are multiple Oracle Application Servers being clustered together as well. I have never dealt with clustering or load balancers before and I wasn't aware that the software had to be written differently in certain areas.

These sound like separate issues to me, but I need help for both.

Answer 1

Concerning your second problem:

If the ConcurrentSessionFilter stopped working (i.e. does not prevent concurrent sessions anymore), that could be due to clustered application containers with sticky sessions.

I such a setup, each of the cluster's nodes works independently and doesn't share state with other nodes. Instead, the load balancer makes sure that existing sessions will always be served by the same node.

Now Spring Security's ConcurrentSessionController works by mapping sessions to principals. The controller itself relies on the HttpSessionEventPublisher sending ApplicationEvents on start and termination of user sessions.

Everything is will work fine if someone intending to open more than one session ends up on the same node he already has a session opened. HttpSessionEventPublisher informs the concurrent session mechanism of the session's creation and authentication will fail because there is already a session associated with this user. On a different node however, there is no session for that user yet, so ConcurrentSessionController does not complain and login succeeds.

Fortunately, solving the problem should be easy: Implement your own SessionRegistry and use a shared data store for all nodes (e.g. the application's database).