Previously DelegatingSecurityContextRunnable and DelegatingSecurityContextCallable
would not setup the SecurityContext if it was on the same thread as it was created.
This was intended to fix SEC-3031 but simply caused more problems.
This commit changes the strategy to keep track of the previous SecurityContext
and restore it (or clear it out if it was originally empty).
Modifying the SecurityContext on the same Thread can cause issues. For example, with a
RejectedExecutionHandler the SecurityContext may be cleared out on the original Thread.
This change modifies both the DelegatingSecurityContextRunnable and DelegatingSecurityContextCallable to,
by default, only modify the SecurityContext if they are invoked on a new Thread. The behavior can be changed
by setting the property enableOnOrigionalThread to true.
This change extends the namespace configuration of <remember-me>
with a 'form-parameter' attribute. The introduced attribute sets
the 'parameter' property of AbstractRememberMeServices.
This enables overriding the default value of
'_spring_security_remember_me' using the namespace configuration.
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.
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 there was a bug introduced by SEC-546 that prevented any
AccountStatusException from being published.
Now AccountStatusExceptions are also published.
Previously subclasses of AbstractSecurityInterceptor did not restore the original
Authentication when RunAsManager was used and an Exception was thrown in the
original method.
AbstractSecurityInterceptor has added a new method finallyInvocation which
should be invoked in a finally block immediately after the original invocation
which will restore the original Authentication. All existing sub classes have
been updated to use this new method.
