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.
Ensure projects have the following so that Maven Central publishing works
- Project name
- Project description
- Project URL
- SCM information
- Javadoc jar
Previously anonymous authentication was submitted as credentials over the wire which
caused the applications to attempt to authenticate the anonymous user.
Now if the user is anonymous (determined by the AuthenticationTrustResolver), the
AuthenticationSimpleHttpInvokerRequestExecutor does not populate any credentials.
Previously Spring Security did not save the Security Context immediately prior
to the following methods being invoked:
- HttpServletResonse.flushBuffer()
- HttpServletResonse.getWriter().close()
- HttpServletResonse.getWriter().flush()
- HttpServletRespose.getOutputStream().close()
- HttpServletRespose.getOutputStream().flush()
This meant that the client could get a response prior to the SecurityContext
being stored. After the client got the response, it would make another request
and this would not yet be authenticated. The reason this can occur is because
all of the above methods commit the response, which means that the server can
signal to the client the response is completed. A similar issue happened in
SEC-398.
Now the previously listed methods are wrapped in order to ensure the SecurityContext
is persisted prior to the response being committed.
When SEC-1950 was introduced it caused problems when a <filter-mapping> was mapped
to multiple dispatchers (i.e. REQUEST and FORWARD) since when the second dispatcher
completed execution it cleared the SecurityContext and the original FilterChain
would then save the cleared out SecurityContext.
We now use a pattern similar to the OncePerRequestFilter to only invoke
SecurityContextHolder.clearContext() on the first invocation of the Filter. We do not simply extend
OncePerRequestFilter because we want to invoke the delegate filters for every request.
Spring Security 3.1 has a regression i the AccessControlListTag
which should support using the bitmask in hasPermission.
Now hasPermission supports bit masks again.
Spring Security 3.0.x allowed developers to pass in a , separated list of permissions.
However, this functionality was accidentally removed in SEC-1560.
The AcessControlListTag now splits the permissions using , as a delimiter
which fixes this passivity issue.
Previously communication errors with LDAP were only logged at debug level.
Communication errors (along with other non-authenticated related NamingExceptions)
are now logged as error messages. We created an InternalAuthetnicationServiceException
to represent errors that should be logged as errors to distinguish between internal
and external authentication failures. For example, we do not want an OpenID Provider
being able to report errors that cause our logs to fill up. However, an LDAP system is
internal and should be trusted so logging at an error level makes sense.
Previously the namespace configuration did not properly set the eraseCredentialsAfterAuthentication
property on the parent AuthenticationProvider when using http@authentication-manager-ref.
Now the ProviderManager that is created by the namespace consults the original
AuthenticationManager to determine if eraseCredentialsAfterAuthentication should
be set on the wrapped instance. If the original is not a ProviderManager the
eraseCredentialsAfterAuthentication is set to false since we should not "magically"
add behavior to the custom AuthenticationManager without knowing the desired behavior.
Due to Eclipse restrictions the classpath adding an project as a dependency picks up
the test dependencies of other projects. This caused problems when running the
config integration tests within Eclipse.
Now the tests specify a specific ldif to load. There is also one new test that ensures
that the ldif is defaulted properly, but does not rely on the ldif that is loaded.
Previously there was no way to extract the original exception or to easily
obtain details about the failure if Spring Security was not able to translate
the exception into a Spring Security AuthenticationException.
Now the caused by is an ActiveDirectoryAuthenticationException which contains
the original Active Directory error code.
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.
The javadoc did not work with JDK 1.5 due to a JDK bug fixed in JDK 1.6.
This changed the javadoc that had a tag that started with <a and was not
closed to escape the < >. This resolves the issue with the JDK 1.5 javadoc
bug.
Previously the javadoc stated that password could not be null. However,
since the introduction of CredentialsContainer introduced in SEC-1493 the
password can be null.
The changes remove the statement that passwords cannot be null. While this
is a non-passive change to the interface, the current state leaves no choice
for a non-passive change. Removing the javadoc was determined the better
option since erasing the credentials was an explicit feature request. Note
that replacing the password with an obscure String can be risky as it
introduces the risk that the value is used to authenticate.
Rob Winch
Spring Buildmaster
mpigg