Behrang Noroozinia (Migrated from SEC-1208) said:
When using create-session="never" in http namespace and security:concurrent-session-control is specified, registerConcurrentSessionControlBeansIfRequired method in HttpSecurityBeanDefinitionParser sets forceEagerSessionCreation to true.
I think this is not required as ConcurrentSessionFilter checks for existence of a session before doing it's job.
My case is that I don't want sessions to be created unless users are logged in, and also I want concurrent session control. Currently, if I want concurrent session control, I'm forced to create sessions for logged out users too which I don't want.
Luke Taylor said:
Use of create-session="never" implies that your application is stateless and doesn't use sessions. It's not a simple thing to change the existing architecture, as the ConcurrentSessionController cannot make a decision unless a session already exists (eager session creation isn't for the benefit of the filter).
Tim Fulmer said:
We've got a case with a custom session registry implemented using the database to store session information for a stateless load balanced deployment. In this case concurrent session control does not make use of the HTTP session at all. However, I can't configure Spring Security with create-session="never" because of this issue. IMHO this is a legitimate use case.
Behrang Noroozinia said:
I still think that requiring eager session creation is not required. Concurrent session filter should only work when there is a session. If there is no session, it can skip it's duties.
I read the registerConcurrentSessionControlBeansIfRequired() method source code and depending on existing of a concurentSession element, it sets forceEagerSessionCreation to true.
IMHO commenting out the las line before return in registerConcurrentSessionControlBeansIfRequired() method will not break any existing code! Or am I missing something?
Yes, I think you are missing something :). I've already pointed out that the filter doesn't make the decision on whether a concurrent session is allowed - that is done when the user attempts to authenticate. The AuthenticationManager calls the ConcurrentSessionController. Let's assume that you have an application configured to only allow one concurrent login. A user who is already logged in then attempts to log in again, but doesn't have a session yet. If, as you suggest, the ConcurrentSessionController should do nothing when there is no session then the user would be authenticated, a session would later be created in order to store the security context and from that point on the user would have two authenticated sessions, so the concurrent session control would be ineffective. forceEagerSessionCreation is explicitly there for this purpose (see SEC-183, for example).
I'm looking into redesigning the concurrent session control implementation in a way that will prevent this issue (and others). Please track SEC-1229 instead.
Fixed as a side-effect of SEC-1229. Sessions are only created when a user is authenticated.