A number of projects had duplicate dependencies on their classpaths
as a result of the same classes being available in more than one
artifact, each with different Maven coordinates. Typically this only
affected the tests, but meant that the actual classes that were
loaded was somewhat unpredictable and had the potential to vary
between an IDE and the command line depending on the order in which
the aritfacts appeared on the classpath. This commit adds a number of
exclusions to remove such duplicates.
In addition to the new exclusions, notable other changes are:
- Spring Data JPA has been updated to 1.4.1. This brings its
transitive dependency upon spring-data-commons into line with
Spring LDAP's and prevents both spring-data-commons-core and
spring-data-commons from being on the classpath
- All Servlet API dependencies have been updated to use the official
artifact with all transitive dependencies on unofficial servlet API
artifacts being excluded.
- In places, groovy has been replaced with groovy-all. This removes
some duplicates caused by groovy's transitive dependencies.
- JUnit has been updated to 4.11 which brings its transitive Hamcrest
dependency into line with other components.
There appears to be a bug in Gradle which means that some exclusions
applied to an artifact do not work reliably. To work around this
problem it has been necessary to apply some exclusions at the
configuration level
Conflicts:
samples/messages-jc/pom.xml
Striping off all leading schemes in the DefaultRedirectStrategy, so it
will be less vulnerable to open redirect phishing attacks. More info can
be found at SEC-2177 JIRA issue.
Previously there was unecessary complexity in CsrfRequestDataValueProcessor
due to the non-passive changes in RequestDataValueProcessor. Now it simply
implements the interface with the methods for both versions of the interface.
This works since linking happens at runtime.
Previously session fixation protection could output an incorrect warning
that session fixation protection did not work.
The code now synchronizes on WebUtils.getSessionMutex(..).
Previously a ClassCastException was thrown if the type was invalid. Now
a flag exists on AuthenticationPrincipal which indicates if a
ClassCastException should be thrown or not with the default being no error.
This also removed the CsrfToken from the response headers to prevent the
token from being saved. If user's wish to return the CsrfToken in the
response headers, they should use the CsrfToken found on the request.
Previously AbstractSecurityWebApplicationInitializer delegated to a
WebApplicationInitializer, but it caused issues in some instances where
a container would pass the annonymous inner class to
SpringServletContainerInitializer which caused errors on startup.
Now AbstractSecurityWebApplicationInitializer registers the
ContextLoaderListener on its own instead of delegating.
Added JavaConfig for Headers. In the process, more HeaderWriter instances
were added so that we can reuse logic between the XML and JavaConfig. This
also prompted repackaging the writers.
This is a distinct filter as apposed to reusing StaticHeaderWriter
since the specification specifies that the "Strict-Transport-Security"
header should only be set on secure requests. It would not make sense to
require DelegatingRequestMatcherHeaderWriter since this requirement is
in the specification.
- hf.doFilter is missing FilterChain argument
- response.headers does not contain the exact values for the headers so
should not be used for comparison (note it is a private member so this
is acceptable)
- hf does not need non-null check when hf.doFilter is invoked
- some of the configurations are no longer valid (i.e. ALLOW-FROM
requires strategy)
- Some error messages needed updated (some could still use improvement)
- No validation for missing header name or value
- rebased off master / merged
- nsa=frame-options-strategy id should use - not =
- FramewOptionsHeaderFactory did not produce "ALLOW-FROM " prefix of origin
- remove @Override on interface overrides to work with JDK5
- Implemented different ALLOW-FROM strategies as specified in the proposal.
Conflicts:
config/src/main/java/org/springframework/security/config/http/HeadersBeanDefinitionParser.java
config/src/test/groovy/org/springframework/security/config/http/HttpHeadersConfigTests.groovy
Created HeadersFilter for setting security headers added including a
bean definition parser for easy configuration of the headers. Enables
easy configuration for the X-Frame-Options, X-XSS-Protection and
X-Content-Type-Options headers. Also allows for additional headers to
be added.
Session fixation protection, whether by clean new session or
migrated session, now publishes an event when a session is
migrated or its ID is changed. This enables application developers
to keep track of the session ID of a particular authentication
from the time the authentication is successful until the time
of logout. Previously this was not possible since session
migration changed the session ID and there was no way to
reliably detect that.
Revised changes per Rob Winch's suggestions.
Previously Spring Security would disable automatically saving the
SecurityContext when the Thread was different than the Thread that
created the SaveContextOnUpdateOrErrorResponseWrapper. This worked for
many cases, but could cause issues when a timeout occurred. The problem
is that a Thread can be reused to process the timeout since the Threads
are pooled. This means that a timeout of a request trigger an apparent
logout as described in the following workflow:
- The SecurityContext was established on the SecurityContextHolder
- An Async request was made
- The SecurityContextHolder would be cleared out
- The Async request times out
- The Async request would be dispatched back to the container upon
timing out. If the container reused the same Thread to process the
timeout as the original request, Spring Security would attempt to
save the SecurityContext when the response was committed. Since the
SecurityContextHolder was still cleared out it removes the
SecurityContext from the HttpSession
Spring Security will now prevent the SecurityContext from automatically
being saved when the response is committed as soon as
HttpServletRequest#startAsync() or
ServletRequest#startAsync(ServletRequest,ServletResponse) is called.
Both overloads of
AbstractAuthenticationProcessingFilter.successfulAuthentication()
claimed to invoke SessionAuthenticationStrategy, which is not true, as
the invokation happens earlier in doFilter(). The Javadoc on these
methods are updated to reflect the actual code.
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 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 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.
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 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.
Previously the documentation was referring to what ConcurrentSessionControlStrategy
performed.
Now the documentation has been moved to the ConcurrentSessionControlStrategy#onAuthentication
method.
Previously SessionFixationProtectionStrategy javadoc mentioned injecting
the SessionRegistry. However, this property is only available on
ConcurrentSessionControlStrategy (a subclass).
Now the mention has been removed. It is apparent the property is required
in ConcurrentSessionControlStrategy since it uses constructor injection.
Previously JdbcTokenRepositoryImpl would log an error with a misleading
message when the token series was missing.
Now JdbcTokenRepositoryImpl logs missing token series at info level with
a more informative message.
There were two issues that needed resolved
- Since DefaultWebSecurityExpressionHandler no longer implemented WebSecurityExpressionHandler a bean lookup by
type would not work. This caused failures in the JSF support.
- The method createEvaluationContext needed to be explicitly defined on WebSecurityExpressionHandler since the
parameterized type from the super interface is not preserved at compile time. Without explicitly defining the
method any class compiled against a previous version would cause a NoSuchMethodException.
This fixes two issues introduced by SEC-1229
* SessionRegistry.registerNewSession is invoked twice
* SessionRegistry.removeSession is invoked twice (once by the
ConcurrentSessionControlStrategy#onSessionChange and once by
SessionRegistryImpl#onApplicationEvent). This is not nearly
as problematic since the interface states that implementations
should be handle removing the session twice. However, as removing
twice requires an unnecessary database hit we should only remove
sessions once.
This should cater for implementations which want to use
the full filtering capabilities while creating a custom
expression root object.
Also cleaning whitespace.
Mattias Severson
Rob Winch
Rob Winch
Maciej Zasada
Julien Dubois
Rob Winch
getvictor
David Alberto
Spring Buildmaster
Adrien be
kazuki43zoo
Marten Deinum
Keesun Baik
Nicholas Williams
Balazs Zagyvai
mpigg
Rob Winch
Tristan Burch
Luke Taylor
Andrei Stefan