Spring Security
  1. Spring Security
  2. SEC-1561

HttpSecurityContextRepository fails to store security context to a newly authenticated session

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.0.5, 3.1.0.M2
    • Component/s: Core
    • Labels:
      None

      Description

      When a second (or later subsequent) authentication attempt arrives on an already authenticated session and session attribute migration is disabled the security context is not always persisted to the new session.

      With an existing authenticated session, subsequent POST requests to the form-login login-processing url will destroy the old session and create a new session. Occasionally the hash code of the persisted security context does not change and so the HttpSecurityContextRepository does not "update" the context stored in the session. The problem is that the old session held the unchanged security context but the new session does not hold any security context. After successfully authenticating another authentication is required because the new session does not contain a SecurityContext.

      One factor causing the HttpSecurityContextRepository to not update/store the SecurityContext is that the session id stored in the security context is the old session id, even after that session has been destroyed and a new one created to replace it. This allows the SecurityContext hashCode to remain the same even though some aspect of the SecurityContext has indeed changed.

      The check to set the security context attribute in HttpSecurityContextRepository.SaveToSessionResponseWrapper.saveContext should probably include something to ensure that the current session actually does contain the context, whether it has changed or not. In the case that the context has not changed, but the session has, the context should be stored to the new session.

        Activity

        Hide
        Derek Scherger added a comment -

        This issue appears to be related to SEC-37, SEC-1307 and SEC-1528.

        Show
        Derek Scherger added a comment - This issue appears to be related to SEC-37 , SEC-1307 and SEC-1528 .
        Hide
        Luke Taylor added a comment -

        I think this should already be fixed in master as internal Spring Security attributes are now migrated by default. However, it would probably still make sense to add a check for the presence of the context attribute in the session, in case a new session has been created for some other reason.

        Show
        Luke Taylor added a comment - I think this should already be fixed in master as internal Spring Security attributes are now migrated by default. However, it would probably still make sense to add a check for the presence of the context attribute in the session, in case a new session has been created for some other reason.
        Hide
        Luke Taylor added a comment -

        When saving the context, I've added a check on whether the context attribute is set in the session, so it will always be saved if a new session has been created during the request.

        Show
        Luke Taylor added a comment - When saving the context, I've added a check on whether the context attribute is set in the session, so it will always be saved if a new session has been created during the request.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Derek Scherger
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: