Spring Security
  1. Spring Security
  2. SEC-1208

http create-session=never throws exception when concurrent session filter is in use

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 RC1
    • Component/s: Namespace
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Luke Taylor added a comment - - edited

          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).

          Show
          Luke Taylor added a comment - - edited 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).
          Hide
          Tim Fulmer added a comment -

          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.

          Show
          Tim Fulmer added a comment - 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.
          Hide
          Behrang Noroozinia added a comment -

          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?

          Show
          Behrang Noroozinia added a comment - 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?
          Hide
          Luke Taylor added a comment -

          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).

          Show
          Luke Taylor added a comment - 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).
          Hide
          Luke Taylor added a comment -

          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.

          Show
          Luke Taylor added a comment - 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.
          Hide
          Luke Taylor added a comment -

          Fixed as a side-effect of SEC-1229. Sessions are only created when a user is authenticated.

          Show
          Luke Taylor added a comment - Fixed as a side-effect of SEC-1229 . Sessions are only created when a user is authenticated.

            People

            • Assignee:
              Luke Taylor
              Reporter:
              Behrang Noroozinia
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: