Spring Security
  1. Spring Security
  2. SEC-2027

FilterChainProxy clearing context causes forwards to clear authentication from the session

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.2
    • Component/s: Web
    • Labels:
      None

      Description

      SEC-1950 added a finally block to the FilterChainProxy doFilter method.

      As a result, it seems that when attempting to render a model and view, the forward from tomcat (using 7.0.28) to get the JSP will be allowed. However, when the SecurityContextPersistenceFilter calls saveContext from its doFilter method, the context is removed from the session as the context after chain execution now has a null authentication object.

      With a second forward in place (using sitemesh) the attempt to get the decorator JSP is denied and the user is redirected back to the login page.

      I debugged under eclipse, put a break point at the following:

      • doFilter in the security context persistence filter
      • wrapRequest (tomcat - ApplicationDispatcher) -> forward
      • save context (from the finally block of do filter of security context persistence filter)

      Observed:

      • do filter is called, which then calls chain.doFilter to continue the chain after creating the session
      • wrap request is called (signalling the forward is occuring to get the jsp)
      • save context is then called which removes the context from the session as it now has a null authentication object

      The next request is redirected back to the login page since no authentication attribute exists in the session.

      Reverted to spring security 3.1.0 and things work fine.

      I have a hard time believing that the change under SEC-1950 was implemented without attempting to render a single model and view, so this may be something funky about our application. However, given that reverted to 3.1.0 allows everything to function correctly, I figured it was worth creating this issue.

      Of note: our JSPs are located in our web application as opposed to statically served so they required authentication. Perhaps this is abnormal configuration?

        Issue Links

          Activity

          Hide
          Rob Winch added a comment -

          Thank you for taking the time to report this issue. The bug appears to be related to when using a <filter-mapping> that processes FORWARD's as shown below. Can you confirm this is something the application in is doing?

          web.xml
              <filter-mapping>
                <filter-name>springSecurityFilterChain</filter-name>
                <url-pattern>/*</url-pattern>
                <dispatcher>REQUEST</dispatcher>
                <dispatcher>FORWARD</dispatcher>
              </filter-mapping>
          

          Typically Spring Security is only used on REQUEST and is not necessary to process forwards. Most developers protect the JSP by placing it in the WEB-INF directory and protecting the URLs that process the REQUEST prior to the FORWARD. This is not to say that this does not need fixed, but this is why it was not discovered until now.

          Show
          Rob Winch added a comment - Thank you for taking the time to report this issue. The bug appears to be related to when using a <filter-mapping> that processes FORWARD's as shown below. Can you confirm this is something the application in is doing? web.xml <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> </filter-mapping> Typically Spring Security is only used on REQUEST and is not necessary to process forwards. Most developers protect the JSP by placing it in the WEB-INF directory and protecting the URLs that process the REQUEST prior to the FORWARD. This is not to say that this does not need fixed, but this is why it was not discovered until now.
          Hide
          Eric Tucker added a comment - - edited

          We have that plus dispatchers for ERROR and INCLUDE (we're eager about security).

          Is the work around to remove having a dispatcher on FORWARDs? I am currently working on upgrading from spring security 2.x to 3.x for our application, so I did not code the original configuration with a dispatcher on FORWARDs. This could be an unnecessary thing (I'll have to verify when I get into work tomorrow).

          Right now it works under 3.1.0, but SEC-1950 talked about memory leaks which I do not want creeping up in the application.

          Show
          Eric Tucker added a comment - - edited We have that plus dispatchers for ERROR and INCLUDE (we're eager about security). Is the work around to remove having a dispatcher on FORWARDs? I am currently working on upgrading from spring security 2.x to 3.x for our application, so I did not code the original configuration with a dispatcher on FORWARDs. This could be an unnecessary thing (I'll have to verify when I get into work tomorrow). Right now it works under 3.1.0, but SEC-1950 talked about memory leaks which I do not want creeping up in the application.
          Hide
          Rob Winch added a comment -

          Thank you for your prompt response and confirming how this occurs. SEC-1950 is more about defensive programming in the event a developer accesses the SecurityContext on URLs that the SessionManagementFilter is not invoked (i.e. If SecurityContext.getContext() is called for a URL that matches security="none" it will not get cleared out). In general, this should not be a problem but it helps developers from making these types of programming errors.

          The work around for now is to use 3.1.0.RELEASE. However, I have already pushed out a fix and it will be included in the 3.1.2.RELEASE which should be out later this week. You can keep an eye out for the release announcement on the Spring Security forums, twitter @SpringSecurity, or the news feed on http://springsource.org.

          Show
          Rob Winch added a comment - Thank you for your prompt response and confirming how this occurs. SEC-1950 is more about defensive programming in the event a developer accesses the SecurityContext on URLs that the SessionManagementFilter is not invoked (i.e. If SecurityContext.getContext() is called for a URL that matches security="none" it will not get cleared out). In general, this should not be a problem but it helps developers from making these types of programming errors. The work around for now is to use 3.1.0.RELEASE. However, I have already pushed out a fix and it will be included in the 3.1.2.RELEASE which should be out later this week. You can keep an eye out for the release announcement on the Spring Security forums , twitter @SpringSecurity , or the news feed on http://springsource.org .
          Hide
          Eric Tucker added a comment -

          I had an http element defined for our login page with security="none". I have since changed it to use an intercept-url tag inside the main http tag for the login page and used the anonymous tag along with IS_AUTHENTICATED_ANONYMOUSLY to allow the login page to be served up without authentication.

          I'll have to proceed with 3.1.0 for now due to time constraints, but I do appreciate the quick response and action. Thank you.

          Show
          Eric Tucker added a comment - I had an http element defined for our login page with security="none". I have since changed it to use an intercept-url tag inside the main http tag for the login page and used the anonymous tag along with IS_AUTHENTICATED_ANONYMOUSLY to allow the login page to be served up without authentication. I'll have to proceed with 3.1.0 for now due to time constraints, but I do appreciate the quick response and action. Thank you.
          Hide
          Rob Winch added a comment -

          No problem. Just to emphasize that the security="none" would only cause problems if you also had code accessing the SecurityContextHolder.getContext() method. Sometimes this can be a bit tricky to detect (i.e. if you use the taglib it will do it) so using the anonymous authentication is probably preferred. I generally only recommend the security="none" approach for static resources (i.e. css, javascript, images, etc).

          The update from 3.1.0 to 3.1.2 should be as easy as updating the version of jars you pull in so hopefully this won't set you back too much. Thanks again for reporting the issue and being so responsive (it helps to get things fixed faster).

          Show
          Rob Winch added a comment - No problem. Just to emphasize that the security="none" would only cause problems if you also had code accessing the SecurityContextHolder.getContext() method. Sometimes this can be a bit tricky to detect (i.e. if you use the taglib it will do it) so using the anonymous authentication is probably preferred. I generally only recommend the security="none" approach for static resources (i.e. css, javascript, images, etc). The update from 3.1.0 to 3.1.2 should be as easy as updating the version of jars you pull in so hopefully this won't set you back too much. Thanks again for reporting the issue and being so responsive (it helps to get things fixed faster).
          Hide
          Farrukh Najmi added a comment -

          I am seeing a similar problem as reported at:

          http://forum.springsource.org/showthread.php?139917-SecurityContext-null-in-index-jsp-because-SecurityContextHolder-cleared-too-early

          Here are my versions for spring modules:

                  <spring.version>3.2.2.RELEASE</spring.version>
                  <spring-security.version>3.1.4.RELEASE</spring-security.version>
                  <spring-security-saml2.version>1.0.0.RC2</spring-security-saml2.version>
                  <spring-ws.version>2.0.0.RELEASE</spring-ws.version>
                  <spring-ldap.version>1.3.1.RELEASE</spring-ldap.version>
          

          Does this look like the same issue?

          Show
          Farrukh Najmi added a comment - I am seeing a similar problem as reported at: http://forum.springsource.org/showthread.php?139917-SecurityContext-null-in-index-jsp-because-SecurityContextHolder-cleared-too-early Here are my versions for spring modules: <spring.version>3.2.2.RELEASE</spring.version> <spring-security.version>3.1.4.RELEASE</spring-security.version> <spring-security-saml2.version>1.0.0.RC2</spring-security-saml2.version> <spring-ws.version>2.0.0.RELEASE</spring-ws.version> <spring-ldap.version>1.3.1.RELEASE</spring-ldap.version> Does this look like the same issue?

            People

            • Assignee:
              Rob Winch
              Reporter:
              Eric Tucker
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: