Implementations of AbstractSecurityExpressionHandler (such as the very commonly used DefaultWebSecurityExpressionHandler) get PermissionEvaluator and RoleHierarchy from the application context (if the application context is provided, and exactly one of such a bean exists in it). This approach matches that used in GlobalMethodSecurityConfiguration, making everything in Spring Security work the same way (including WebSecurity).
Issue gh-4077
Gradle is easy enough to import into IDEs, so pom.xml should no
longer be necessary.
This commit removes the pom.xml files from the build.
Fixes gh-4283
GrantedAuthorityImpl has been replaced a couple of years ago with
SimpleGrantedAuthority and this commit fixes the documentation items
which weren’t updated to reflect this change.
Fixes gh-4163.
This commit creates a UserBuilder and updates samples to use it. We do not
leverate it for JdbcUserDetailsManager because it requires the schema to
be created which is difficult with a single bean definition and
unpredicatble ordering. For this, it is still advised to use
AuthenticationManagerBuilder
Fixes gh-4095
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
Introduced `RoleHierarchyUtils` which enables convenient
construction of `RoleHierarchy` from map based representation.
Where the map key is the role name and the map value is a list
of implied role names.
Here is a small example for that in action:
https://gist.github.com/thomasdarimont/ee9fffdef1adb9243b12ad247478aad4Fixes#3990.
Signed-off-by: Thomas Darimont <thomas.darimont@gmail.com>
Signed-off-by: Thomas Darimont <thomas.darimont@gmail.com>
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
Previously the JSON modules didn't use Spring's Assert.
This commit changes the assertions to use Spring's Assert and does
some minor restructuring.
Issue gh-3736
According to the SpringSecurityMessageSource documentation class which uses
SpringSecurityMessageSource should also implement MessageSourceAware interface
in order to support alternative message source.
Issue gh-4048
Document why InteractiveAuthenticationEvent doesn't extend
AuthentcationEvent. This is to avoid multiple AuthenticationSuccessEvent
from being sent to any listeners.
Fixes gh-3857
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
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.
Previously there were some incorrect dependency versions. This commit fixes
that.
We added dependencyManagement for Spring Framework and corrected
Thymeleaf and embedded redis versions.
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
The method setPseudoRandomNumberBits actually sets the number of bytes. This
commit deprecates setPseudoRandomNumberBits and adds
setPseudoRandomNumberBytes. The default value is still 256 to remain passive
but will be updated in 4.x.
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.
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 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.
This should cater for implementations which want to use
the full filtering capabilities while creating a custom
expression root object.
Also cleaning whitespace.