Spring Security
  1. Spring Security
  2. SEC-2028

Support remember me and concurrency control

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Currently the concurrency control does not work with remember me. It would be good to support this out of the box.

        Issue Links

          Activity

          Hide
          Sergey Chunayev added a comment -

          Lucas, thank you very much.
          There's also hope that spring security team finds a way to address this issue in some standard way. I just wanted to make sure that the problem I'm having is a known issue and I'm not doing something wrong.

          Show
          Sergey Chunayev added a comment - Lucas, thank you very much. There's also hope that spring security team finds a way to address this issue in some standard way. I just wanted to make sure that the problem I'm having is a known issue and I'm not doing something wrong.
          Hide
          Matthew Fleming added a comment - - edited

          I ran into this same issue but I guess I'm not sure what I'm missing with my fix?

          This seems like a pretty simple extension to the filter:

          /**
           * A remember me filter which respects the session strategy
           */
          public class SessionStrategyBasedRememberMeFilter extends RememberMeAuthenticationFilter {
          
              private SessionAuthenticationStrategy sessionStrategy = new NullAuthenticatedSessionStrategy();
          
              public SessionStrategyBasedRememberMeFilter(AuthenticationManager authenticationManager, RememberMeServices rememberMeServices, SessionAuthenticationStrategy sessionStrategy) {
                  super(authenticationManager, rememberMeServices);
                  this.sessionStrategy = sessionStrategy;
              }
          
              @Override
              protected void onSuccessfulAuthentication(HttpServletRequest request, HttpServletResponse response, Authentication authResult) {
                  if (sessionStrategy != null){
                      sessionStrategy.onAuthentication(authResult, request, response);
                  }
              }
          }
          
          Show
          Matthew Fleming added a comment - - edited I ran into this same issue but I guess I'm not sure what I'm missing with my fix? This seems like a pretty simple extension to the filter: /** * A remember me filter which respects the session strategy */ public class SessionStrategyBasedRememberMeFilter extends RememberMeAuthenticationFilter { private SessionAuthenticationStrategy sessionStrategy = new NullAuthenticatedSessionStrategy(); public SessionStrategyBasedRememberMeFilter(AuthenticationManager authenticationManager, RememberMeServices rememberMeServices, SessionAuthenticationStrategy sessionStrategy) { super (authenticationManager, rememberMeServices); this .sessionStrategy = sessionStrategy; } @Override protected void onSuccessfulAuthentication(HttpServletRequest request, HttpServletResponse response, Authentication authResult) { if (sessionStrategy != null ){ sessionStrategy.onAuthentication(authResult, request, response); } } }
          Hide
          Lucas Ward added a comment -

          Matthew,

          I believe I tried that as the very first thing, but ran into issues. It's been awhile, so I can't remember. It's possible I missed something simple though.

          If memory serves. The big problem was always the session timeout issue, and in my testing it didn't work. But, I was a bit under the gun at the time. Have you tried setting session timeout in a dev instance really low and playing around with it? What happened in the scenarios where the first logged in user was timed out, but then a second logs in, and then the first comes back again, but is this time authenticated with a token auth, rather than username and password? Or if both of them timeout and come back? I was never able to get that to work with the simple filter extension you've done. (again, could have made a mistake...)

          Show
          Lucas Ward added a comment - Matthew, I believe I tried that as the very first thing, but ran into issues. It's been awhile, so I can't remember. It's possible I missed something simple though. If memory serves. The big problem was always the session timeout issue, and in my testing it didn't work. But, I was a bit under the gun at the time. Have you tried setting session timeout in a dev instance really low and playing around with it? What happened in the scenarios where the first logged in user was timed out, but then a second logs in, and then the first comes back again, but is this time authenticated with a token auth, rather than username and password? Or if both of them timeout and come back? I was never able to get that to work with the simple filter extension you've done. (again, could have made a mistake...)
          Hide
          Matthew Fleming added a comment -

          Here's the test cases that I have run through and have been successful with. I'm running tomcat 7 with the "preserve sessions across restarts" turned off. This is because the the concurrency filter doesn't work properly (serialize) when the option is on.

          • start chrome, login (w/remember me). start firefox, login (with remember me). Verify chrome browser is invalided.
          • start chrome, login (w/remember me). close chrome. start firefox, login (w/remember me). close firefox. Open chrome, open firefox, verify chrome invalidated.
          • start chrome, login (w/remember me). close chrome. start firefox, login (w/remember me). close firefox. bounce tomcat. open firefox, open chrome, verify firefox invalidated.

          I think the key to this is also the invalidation of the session when the concurrent filter fires. I do this by specifying our logout uri as the 'expired url'.

          Here is our config:

              @Bean
              public ConcurrentSessionFilter getConcurrencyFilter() {
                  // go to the logout page or the remember me will override the concurrent logout
                  return new ConcurrentSessionFilter(getSessionRegistry(), "/j_spring_security_logout");
              }
          
              @Bean
              public SessionFixationProtectionStrategy getSessionFixationProtectionStrategy() {
                  ConcurrentSessionControlStrategy ret = new ConcurrentSessionControlStrategy(getSessionRegistry());
                  ret.setMaximumSessions(1);
                  return ret;
              }
          
              @Bean
              public SessionRegistry getSessionRegistry() {
                  return new SessionRegistryImpl();
              }
          
          Show
          Matthew Fleming added a comment - Here's the test cases that I have run through and have been successful with. I'm running tomcat 7 with the "preserve sessions across restarts" turned off. This is because the the concurrency filter doesn't work properly (serialize) when the option is on. start chrome, login (w/remember me). start firefox, login (with remember me). Verify chrome browser is invalided. start chrome, login (w/remember me). close chrome. start firefox, login (w/remember me). close firefox. Open chrome, open firefox, verify chrome invalidated. start chrome, login (w/remember me). close chrome. start firefox, login (w/remember me). close firefox. bounce tomcat. open firefox, open chrome, verify firefox invalidated. I think the key to this is also the invalidation of the session when the concurrent filter fires. I do this by specifying our logout uri as the 'expired url'. Here is our config: @Bean public ConcurrentSessionFilter getConcurrencyFilter() { // go to the logout page or the remember me will override the concurrent logout return new ConcurrentSessionFilter(getSessionRegistry(), "/j_spring_security_logout" ); } @Bean public SessionFixationProtectionStrategy getSessionFixationProtectionStrategy() { ConcurrentSessionControlStrategy ret = new ConcurrentSessionControlStrategy(getSessionRegistry()); ret.setMaximumSessions(1); return ret; } @Bean public SessionRegistry getSessionRegistry() { return new SessionRegistryImpl(); }
          Hide
          marc schipperheyn added a comment -

          I struggled with this a while ago, left it, and came back to it today. On Stackoverflow Luke Taylor specifies this as simple and possible: http://stackoverflow.com/questions/10587881/spring-security-sessionregistry-with-persistenttokenbasedremembermeservices I'm a little confused about the status of this issue. Also b/c it's kidn of hard to believe that this would not be there.

          Show
          marc schipperheyn added a comment - I struggled with this a while ago, left it, and came back to it today. On Stackoverflow Luke Taylor specifies this as simple and possible: http://stackoverflow.com/questions/10587881/spring-security-sessionregistry-with-persistenttokenbasedremembermeservices I'm a little confused about the status of this issue. Also b/c it's kidn of hard to believe that this would not be there.

            People

            • Assignee:
              Unassigned
              Reporter:
              Rob Winch
            • Votes:
              9 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated: