Spring Security
  1. Spring Security
  2. SEC-1327

Documentation: Session handling, spring_security_login, pre authenticated filters

    Details

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

      Description

      I believe the documentation could be better and say:
      1. The HttpSessionSecurityContextRepository will store the SecurityContext in the HttpSession if one exists even if the class has allowSessionCreation=false.
      2. spring_security_login creates a session.
      3. This means that AbstractPreAuthenticatedProcessingFilter may find the SecurityContext and not proceed with the pre-authentication path.
      4. A useful pre-authentication applicationContext-security.xml starting point would be useful. e.g. one that prevents session creation and doesn't use form-login.

      Justification:
      I've been writing a pre-authentication filter to integrate with the RPX SaaS OpenID service. My application is REST so I never wanted a session to be created. As a starting point I used the expanded version of the http namespace configuration.

      While writing my filter I assumed that there would be no session and therefore the successfulAuthentication() method would be called. In that method I have a redirect which I want to fire on a new sign-in.

      However, if the user goes to a page as anonymous which does not allow access they get the spring_security_login. This creates a session which is then used on subsequent logins and the redirect doesn't happen.

      I feel that a few improvements to the documentation would have prevented this defect.

      Code snippets to explain my mistake:
      applicationContext-security.xml
      <http create-session="never">
      <form-login />
      <http-basic />
      <logout />
      <intercept-url pattern="/index.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
      <intercept-url pattern="/**" access="ROLE_USER" />
      <custom-filter position="PRE_AUTH_FILTER" ref="rpxFilter"/>
      </http>

      RpxFilterImpl extends AbstractPreAuthenticatedProcessingFilter
      @Override
      protected void successfulAuthentication(HttpServletRequest request, HttpServletResponse response, Authentication authResult) {
      if (getSessionCodeFromRequest(request) == null)

      { User user = (User)authResult.getPrincipal(); Session session = sessionRepository.createSession(user); Cookie sessionCookie = new Cookie(SESSION_COOKIE_NAME, session.getSessionCode()); sessionCookie.setPath("/"); response.addCookie(sessionCookie); }

      super.successfulAuthentication(request, response, authResult);

      // We get called for other urls so we only want to redirect
      // if this is an actual sign in.
      logger.debug("requestUri: " + request.getRequestURI());
      if (tokenUrl.equals(request.getRequestURI())) {
      try

      { redirectStrategy.sendRedirect(request, response, "/editPersonalRoute_extjs3.html"); }

      catch (IOException e)

      { logger.error("Error during redirect from security", e); }

      }
      }

        Activity

        Hide
        Luke Taylor added a comment -

        If you choose to use form login, then it's pretty rare that you would be doing so without using a session. However, if you set create-session="never", then a session should not be created. If it is then it's a bug.

        Likewise with spring_security_login, which shouldn't create a session unless it is allowed to. The only call to getSession() in the relevant class uses

        if (loginError) {
        HttpSession session = request.getSession(false);

        If possible, please clarify where the session is being created.

        Show
        Luke Taylor added a comment - If you choose to use form login, then it's pretty rare that you would be doing so without using a session. However, if you set create-session="never", then a session should not be created. If it is then it's a bug. Likewise with spring_security_login, which shouldn't create a session unless it is allowed to. The only call to getSession() in the relevant class uses if (loginError) { HttpSession session = request.getSession(false); If possible, please clarify where the session is being created.
        Hide
        Luke Taylor added a comment -

        Not a bug

        Show
        Luke Taylor added a comment - Not a bug
        Hide
        Eyal added a comment -

        I newbie to Spring Frame work.
        according to a book, that is my guide, I have to use FilterToBeanProxy for tunneling the security issue form the web.xml to Spring Framework.

        How It can be done now?

        Thanks,
        Eyal.

        Show
        Eyal added a comment - I newbie to Spring Frame work. according to a book, that is my guide, I have to use FilterToBeanProxy for tunneling the security issue form the web.xml to Spring Framework. How It can be done now? Thanks, Eyal.
        Hide
        Luke Taylor added a comment -

        Hi Eyal. This is not an appropriate place for asking random questions. Please read the documentation, look at the samples and use the support forum for any specific questions to which you cannot find an answer elsewhere.

        Show
        Luke Taylor added a comment - Hi Eyal. This is not an appropriate place for asking random questions. Please read the documentation, look at the samples and use the support forum for any specific questions to which you cannot find an answer elsewhere.
        Hide
        Edward Sargisson added a comment -

        Luke: I agree this isn't a code defect. I do still think the documentation could be better though.

        However, after your comment above I wanted to find where the session was being created (because I wanted to prove you wrong...) and, to my surprise, found that it was my index.jsp. Adding session="false" to the page directive solved the problem.

        Therefore point 2 in this item is incorrect. However, I believe the changes in the rest of this item would be very useful.

        Show
        Edward Sargisson added a comment - Luke: I agree this isn't a code defect. I do still think the documentation could be better though. However, after your comment above I wanted to find where the session was being created (because I wanted to prove you wrong...) and, to my surprise, found that it was my index.jsp. Adding session="false" to the page directive solved the problem. Therefore point 2 in this item is incorrect. However, I believe the changes in the rest of this item would be very useful.
        Hide
        Luke Taylor added a comment -

        I've added some extra Javadoc to HttpSessionSecurityContextRepository and AbstractPreAuthenticatedProcessingFilter and a minor addition to the suggestion in the docs about using a null implementation of SessionSecurityContextRepository to prevent if you don't want the context stored. I don't think it is the kind of thing that should have extensive coverage be in the user manual. There is already a pre-authentication sample with an configuration file. Making your application stateless is a separate concern and the most common error is that the user creates a session somewhere themselves (typically in a JSP, as was the case here).

        Show
        Luke Taylor added a comment - I've added some extra Javadoc to HttpSessionSecurityContextRepository and AbstractPreAuthenticatedProcessingFilter and a minor addition to the suggestion in the docs about using a null implementation of SessionSecurityContextRepository to prevent if you don't want the context stored. I don't think it is the kind of thing that should have extensive coverage be in the user manual. There is already a pre-authentication sample with an configuration file. Making your application stateless is a separate concern and the most common error is that the user creates a session somewhere themselves (typically in a JSP, as was the case here).

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Edward Sargisson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: