Previously DummyRequest implemented HttpServletRequest which caused complications
since Servlet 2.5 and Servlet 3 had non passive changes. While we were "safe" if the
Servlet 3 methods were never invoked reflective access of the methods would also
problems. We could prevent users from accessing the methods of DummyRequest by
returning new HttpServletRequestWrapper(DummyRequest), but a debugger could
potentially try to iterate over the methods triggering a NoClassDefFoundError.
DummyRequest now extends HttpServletRequestWrapper which will be dynamically
linked to the proper version of HttpServletRequest. We use a Dynamic Proxy that
throws UnsupportedOperationException to implement any methods we are not
interested in.
Previously SecurityContextCallableProcessingInterceptor used afterCompletion
to clear the SecurityContextHolder. This does not work since afterCompletion
is invoked on the Servlet Container thread.
Now SecurityContextCallableProcessingInterceptor clears the
SecurityContextHolder on postProcess which is invoked on the same thread
that the Callable is processed on.
Previously, if the Principal returned by getPreAuthenticatedPrincipal was not a String,
it prevented requiresAuthentication from detecting when the Principal was the same.
This caused the need to authenticate the user for every request even when the Principal
did not change.
Now requiresAuthentication will check to see if the result of
getPreAuthenticatedPrincipal is equal to the current Authentication.getPrincipal().
Previously a NullPointerException would occur if an HttpServletRequest.getMethod()
returned null.
Now AntPathRequestMatcher and RegexpRequestMatcher will handle if the
HttpServletRequest.getMethod() returns null. While under normal circumstances,
it is unlikely for the method to be null this can occur when using
DefaultWebInvocationPrivilegeEvaluator.isAllowed(String, Authentication).
Previously SaveContextOnUpdateOrErrorResponseWrapper would save the SecurityContext on a different
Threads than the one it was created on. This causes issues with Async Web requests which may write
to the response on a new Thread.
Now SaveContextOnUpdateOrErrorResponseWrapper will not save the SecurityContext when a different
Thread invokes any of the methods that commit the response. This prevents issues with Async
processing. However, explicit calls to SecurityContextRepository.save will still save the
SecurityContext since it invokes the saveRequest method rather than private doSave method within
the SaveContextOnUpdateOrErrorResponseWrapper which contains the logic to prevent saving from
another Thread.
Previously a ConcurrentModificationException could occur when
PointcutExpression.matchesMethodExecution was performed in multiple threads. Another
issue was that beans may get processed multiple times.
Now a lock is performed to ensure that only a single thread has access to
PointcutExpression.matchesMethodExecution and that each bean only gets processed once.
Provide abstractions for transferring a SecurityContext across threads.
The main concepts are the DelegatingSecurityContextCallable and the
DelegatingSecurityContextRunnable which contain a SecurityContext to establish before
delegating to a Callable or Runnable.
There are also wrapper implementations for each of the key java.util.concurrent and
spring task interfaces to make using the DelegatingSecurityContextCallable and
DelegatingSecurityContextRunnable transparent to users. For example a
DelegatingSecurityContextTaskExecutor which can be injected with a specific
SecurityContext or use the SecurityContext from the SecurityContextHolder at the time the
task is submitted. There are similar implementations for each of the key
java.util.concurrent and spring task interfaces.
Note that in order to get DelegatingSecurityContextExecutorService to compile with
JDK 5 or JDK 6 we could not use type safe methods. See
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6267833 for details.
This can be used to generate the pom.xml for adding the Spring Security
snapshot jars as a Maven Dependency to another project. For example,
if mywebapp requires the Spring Security 3.1.4.CI-SNAPSHOT jars one
could generate the pom.xml files and then use that to convert the project
into a valid Maven project within the IDE. Then the SNAPSHOT dependendies
could be added to mywebapp. This prevents the need to install the SNAPSHOT
dependencies in the local Maven repository.
Previously the build would look up a server port dynamically, but since
it closed the port immediately it may not be reserved by the time jetty
started up.
We now reserve the port and do not close it till just before Jetty starts.
While there is still a race condition, it is much smaller window of time
than it was previously.
Previously authenticating a user could take significantly longer than
determining that a user does not exist. This was due to the fact that only
users that were found would use the password encoder and comparing a
password can take a significant amount of time. The difference in the
time required could allow a side channel attack that reveals if a user
exists.
The code has been updated to do comparison against a dummy password
even when the the user was not found.
Previously the SwitchUserFilter was logging as an error and then
throwing an Exception immediately after. This is not correct, since
whomever is catching the Exception should choose to log an error or not.
Now the log statement is at a debug level.
Previously there was a race condition could occur when the user attempts to access
a slow resource and then logs out which would result in the user not being logged
out.
SecurityContextLogoutHandler will now remove the Authentication from the
SecurityContext to protect against this scenario.
Previously, ConcurrentSessionFilter was placed after SecurityContextPersistenceFilter
which meant that the SecurityContextHolder was empty when ConcurrentSessionFilter was
invoked. This caused the Authentication to be null when performing a logout. It also
caused complications with LogoutHandler implementations that would be accessing the
SecurityContextHolder and potentially clear it out expecting that
SecurityContextPersistenceFilter would then clear the SecurityContextRepository.
The ConcurrentSessionFilter is now positioned after the
SecurityContextPersistenceFilter to ensure that the SecurityContextHolder is populated
and cleared out appropriately.
Rob Winch
Spring Buildmaster
mpigg