Spring Security
  1. Spring Security
  2. SEC-1190

preAuth does not detect a change in the SSO header

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 RC1
    • Component/s: Core
    • Labels:
      None

      Description

      I configured the sso preauth

      I configured the
      <property name="principalRequestHeader" value="ct-remote-user" />

      and this is correctly picking up the user to establish the session. The issue is if the user ends his sso session and starts a new one - the session on the app server (running the spring stack) still has an existing session and it does not seem that the value of this ct-remote-user is checked after the initial session is established. So the user will rejoin under the prior id.

      Attached is a solution we worked on with Stefan from support. This could be improved upon as we found we needed to fully cleanup the session itself.

      In test this is a verey common occurance and also for us we use different instances of the SSO for the development areas, so it helps when switching between QA and Prod environments.

      1. securitysso-config.xml
        2 kB
        Mark Diskin
      2. securitysso-config.xml
        2 kB
        Mark Diskin

        Activity

        Hide
        Luke Taylor added a comment -

        I've added a checkForPrincipalChanges property to AbstactPreAuthenticatedProcessingFilter, which is a more generic solution. If set, the filter will do a comparison of the pre-authenticated principal value against the name stored in the current Authentication object. If they don't match, it will reauthenticate the user with the new principal.

        Show
        Luke Taylor added a comment - I've added a checkForPrincipalChanges property to AbstactPreAuthenticatedProcessingFilter, which is a more generic solution. If set, the filter will do a comparison of the pre-authenticated principal value against the name stored in the current Authentication object. If they don't match, it will reauthenticate the user with the new principal.
        Hide
        Mark Diskin added a comment -

        Great.

        After posting this I had to make another change to allow for the session to be invalidated, as I had other objects in state - i.e. I did not want the new user to have objects belong to the old.

        HttpSession session = request.getSession(false);

        if (session != null)

        { session.invalidate(); }

        Without this I don't this this new feture would be something we could use.

        Thanks
        }

        Show
        Mark Diskin added a comment - Great. After posting this I had to make another change to allow for the session to be invalidated, as I had other objects in state - i.e. I did not want the new user to have objects belong to the old. HttpSession session = request.getSession(false); if (session != null) { session.invalidate(); } Without this I don't this this new feture would be something we could use. Thanks }
        Hide
        Luke Taylor added a comment -

        It sounds like you need a logout link .

        I've added an "invalidateSessionOnPrincipalChange" property to AbstactPreAuthenticatedProcessingFilter. If set to true (the default) and a new principal is detected, the existing session will be invalidated before proceeding to re-authenticate the user.

        Show
        Luke Taylor added a comment - It sounds like you need a logout link . I've added an "invalidateSessionOnPrincipalChange" property to AbstactPreAuthenticatedProcessingFilter. If set to true (the default) and a new principal is detected, the existing session will be invalidated before proceeding to re-authenticate the user.
        Hide
        Mark Diskin added a comment -

        We have a logout but folks like to avoid it. We have a number of folks especially during the development switching login user's on the SSO side and messing up existing sessions on the pre-auth application side.

        Thanks - looking forward to the new 3.0 version - now we have to get the Jasper folks to adopt it so we can correctly configure their Spring Security code to work with our SSO (they still have the acegi base that was targetted to siteminder).

        Show
        Mark Diskin added a comment - We have a logout but folks like to avoid it. We have a number of folks especially during the development switching login user's on the SSO side and messing up existing sessions on the pre-auth application side. Thanks - looking forward to the new 3.0 version - now we have to get the Jasper folks to adopt it so we can correctly configure their Spring Security code to work with our SSO (they still have the acegi base that was targetted to siteminder).

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Mark Diskin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: