Previous to this commit, role prefix had to be set in every class
causing repetition. Now, bean `GrantedAuthorityDefaults` can be used to
define the role prefix in a single point.
Fixes gh-3701
* Use new test method name convention of
methodNameWhen<Condition>Then<Expectation>
* Check null Cookie
* Check Cookie.getName() for crlf since we do not want to rely on the
implementation. For example Cookie could be overriden by extending it.
* Use Crlf as convention instead of CLRF as style guide
* Create new FirewalledResponse before each test to ensure isolation
* Use Mock for HttpServletResponse delegate to keep test in isolation (i.e.
we do not want our tests to fail if MockHttpServletRequest changes an
Exception error message)
Issue gh-3910
* Fix passivity and add tests
* Introduce SessionInformationExpiredEvent as a value object
* Rename ExpiredSessionStrategy to SessionInformationExpiredStrategy
to account for the need of SessionInformation
* Switch to Constructor Injection
* Move the changes to the xsd to 4.2 xsd instead of 4.1
Issue gh-3808
This commit adds an ExpiredSessionStrategy for the ConcurrentSessionFilter
analogous to the InvalidSessionStrategy for the SessionManagementFilter. It also
adds a configuration option for both the InvalidSessionStrategy and
ExpiredSessionStrategy to the XML namespace and Java configuration.
Fixes gh-3794
Fixes gh-3795
We have an issue where token strings that contain a colon break
the existing decoding strategy, which tokenizes on colons. This
change urlencodes the individual tokens when creating the cookie
string; and urldecodes them decoding the cookie and extracting the
tokens. This also eliminates the need for existing code to deal with
openid tokens which contain urls, and thus colons.
Fixes gh-3355
Issue gh-3736
* ClassLoader argument - this is required because we do not want to assume
the ClassLoader that should be used
* Clean up logging - logging is now at debug level because we don't expect
all of the modules are loaded (they are quite possibly off the ClassPath)
* Remove ObjectUtils as it was being used on methods that expect a
Collection or Array with non collection based objects
* Polish Javadoc warnings
The validation does not work due to restrictions within the servlet
container. Specifically we cannot access the servlets that are registered.
This commit reverts the validation logic for MvcRequestMatcher to determine
if servletPath is required.
Fixes gh-4027
This commit adds a check for rememberme to the ExceptionTranslationFilter.
Using this when someone isn't fully authenticated he will be prompted with a
login screen and after that will be redirected to the original requested URI.
Fixes gh-2427
Currently CookieCsrfTokenRepository does not specify that the httpOnly
flag needs set to false. We should update the reference to include this
setting (and a comment about it) since it states that the settings will
work with AngularJS.
This commit updates the documentation and provides a convenience factory
method to create a CookieCsrfTokenRepository with cookiHttpOnly=false
Fixes gh-3865
It is now possible to provide a SpEL expression for
@AuthenticationPrincipal. This allows invoking custom logic including
methods on the principal object.
Fixes gh-3859
* Rename to DelegatingLogoutSuccessHandler for consistency
* Remove JavascriptOriginRequestMatcher in favor of
RequestHeaderRequestMatcher
Issue gh-3282
OnCommittedResponseWrapper trackContentLength will throw a
NullPointerException when the content length passed in is null.
This commit properly tracks the null value as a length of 4.
Fixes gh-3823
Perviously there were issues with case insenstive patterns and URI
variables that contained upper case characters. For example, the pattern
"/user/{userId}" could not resolve the variable #userId Instead it was
forced to lowercase and #userid was used.
Now if the pattern is case insensitive then so is the variable. This means
that #userId will work as will #userid.
Fixes gh-3786
Previously Spring Security always wrote cache control headers and relied
on the application to override the values. This can cause problems with
cache control. For example, applications may only set cache control if
the header is not already set. Additionally, setting of Cache-Control
should disable writing of Pragma.
This commit delays writing headers until just before the response is
committed and only writes the Cache Control headers if they do not exist.
Fixes gh-2953
HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites
to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates.
(For example, sometimes attackers can compromise certificate authorities,
and then can mis-issue certificates for a web origin.)
The HTTPS web server serves a list of public key hashes, and on subsequent connections
clients expect that server to use 1 or more of those public keys in its certificate chain.
This commit will add this new functionality.
Fixes gh-3706
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.
Previously SecurityContextHolderAwareRequestWrapper always prefixed with
rolePrefix. This meant the defaults would never return true for a role
that started with the prefix (i.e. ROLE_).
We no longer apply the rolePrefix if the value passed in already starts
with rolePrefix.
This ensures that Spring Session & Security's logic for performing
a save on the response being committed can easily be kept in synch.
Further this ensures that the SecurityContext is now persisted when
the response body meets the content length.
Previously there were some incorrect dependency versions. This commit fixes
that.
We added dependencyManagement for Spring Framework and corrected
Thymeleaf and embedded redis versions.
Previously DefaultLoginPageGeneratingFilter would match on /**/login
which was not ideal since other parts of the application may want to
match on the URL.
Now it matches on /login.
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().
Add the DelegatingAuthenticationFailureHandler class to support
map each exception to AuthenticationFailureHandler. This class gives
more powerful options to customize default behavior for users.
Previously SavedRequestAwareWrapper overrode the getCookies() method. This
meant that the cookies from the original request were used instead of the
new request. In general, this does not make sense since cookies are
automatically submitted in every request by a client. Additionally, this
caused problems with using a locale cookie that was specified after the
secured page was requested.
Now SavedRequestAwareWrapper uses the new incoming request for determining
the cookies.
In order to get better error messages (avoid NullPointerException) the
HttpSessionEventPublisher now gets the required ApplicationContext which
throws an IllegalStateException with a good error message.
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.
Milan Ševčík
Rob Winch
Eddú Meléndez
Gabriel Lavoie
Julio Valcarcel
Marten Deinum
Joe Grandja
Dennis Kieselhorst
Stefan Penndorf
Jeremy Waters
Jitendra Singh Bisht
Joe Grandja
Spring Buildmaster
Ruben Dijkstra
Adrien SAUVEZ
bartolom
Li Weinan
Shazin Sadakath
Rob Winch
Johnny Lim
Simon Olofsson
Andrew NS Yeow
Billy Korando
Alex Baxanean
Shazin Sadakath
Tim Ysewyn
Andrei Ivanov
Alex Panchenko
zhanhb
Thomas Darimont
Gunnar Hillert
Pascal Gehl
Michael Cramer
Marcin Mielnicki
Stillglade
Rob Winch
Kazuki Shimizu
bcecchinato
Mattias Severson
Maciej Zasada
Julien Dubois
getvictor
David Alberto
Adrien be
kazuki43zoo
Keesun Baik
Nicholas Williams
Balazs Zagyvai
mpigg
Rob Winch
Tristan Burch
Luke Taylor
Andrei Stefan