Previously the crypto module was not exported in Eclipse because it was
listed as a test dependency to have it added as a dependency. Note that
this was all to work around GRADLE-1116
Now we add an included configuration that is exported for Eclipse, but not
added to the Maven pom (since all the crypto module is included in core).
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.
Previously wiring dependencies created with a FactoryBean into
MethodSecurityExpressionHandler &
MethodSecurityExpressionHandler.expressionParser and would cause
NoSuchBeanDefinitionException's to occur. These changes make it easier
(but not impossible) to avoid such errors.
The following changes were made:
- ExpressionBasedAnnotationAttributeFactory delays the invocation of
MethodSecurityExpressionHandler.getExpressionParser()
- MethodSecurityExpressionHandler is automatically wrapped in a
LazyInitTargetSource and marked as lazyInit=true
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 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 there was a bug introduced by SEC-546 that prevented any
AccountStatusException from being published.
Now AccountStatusExceptions are also published.
Rob Winch
Spring Buildmaster
Guillaume Smet
Oliver Becker
Georges-Etienne Legendre
Marten Deinum