Details

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.

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?

Activity

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.

Rob Winch
added a comment - 07/Aug/12 1:09 PM 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.

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.

Eric Tucker
added a comment - 07/Aug/12 2:51 PM - 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.

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.

Rob Winch
added a comment - 07/Aug/12 3:01 PM 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 .

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.

Eric Tucker
added a comment - 07/Aug/12 3:28 PM 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.

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).

Rob Winch
added a comment - 07/Aug/12 3:36 PM 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).

This has been fixed in Spring Security 3.1.2.RELEASE+. Please try updating to the latest version of Spring Security 3.2.5.RELEASE. The release is passive and should not cause you to do anything but change your pom files.

Rob Winch
added a comment - 14/Nov/14 5:41 AM This has been fixed in Spring Security 3.1.2.RELEASE+. Please try updating to the latest version of Spring Security 3.2.5.RELEASE. The release is passive and should not cause you to do anything but change your pom files.