Renamed OidcReactiveAuthenticationManager to
OidcAuthorizationCodeReactiveAuthenticationManager since it only handles
authorization code flow.
Fixes: gh-5530
This exposes #authenticationEntryPoint(), #accessDeniedHandler, on
the Resource Server DSL.
With these, a user can customize the error responses when a bearer
token request fails.
Fixes: gh-5497
This introduces #bearerTokenResolver(BearerTokenResolver) to the
Resource Server DSL, allowing users to configure the resolver to allow
the access token as part of the request body or a query parameter. It
also allows the user to replace the resolver with a completely custom
one.
This also introduces the same ability by exposing a bean of type
BearerTokenResolver
Fixes: gh-5496
For the remember me test, there is some hand configuration that was
carried over from the groovy test as there isn't a way via the xml
config to achieve the same result.
For the attribute exchange test, in order to reduce the amount of
endpoint configuration, the test uses a bit of reflection to disable
the OpenID association step. This is because the xml config does not
support wiring a custom ConsumerManager, like the java configurer
does.
Issue: gh-4939
Note that originally there were five tests in the groovy test, however
the last one, multipleAuthenticationManagersWorks, turned out to be a
duplicate after creating the test
requestWhenUsingMutuallyExclusiveHttpElementsThenIsRoutedAccordingly
As such, the new file contains just four tests.
Issue: gh-4939
The actual method signature look this this:
```java
protected void configure(AuthenticationManagerBuilder auth) throws Exception
```
This PR aims at aligning the javadoc for this annotation with the actual method signature.
This introduces BearerTokenAuthenticationFilter to SecurityFilters so
that it can be used in the various addFilter methods and with the
`custom-filter` xml tag.
Fixes: gh-5479
Some of Resource Server Configurer's tests were relying on specific
error messaging from Nimbus and from the JDK, which makes them
brittle.
These tests now simply confirm that resource server responses
contain the correct error state without relying on specific wording
outside of our control.
It is quite likely we will need to prevent certain Exceptions from being
saved or from triggering a saved request. When we add support for this,
we can now leverage @Transient vs creating a new annotation.
Issue: gh-5481
Introducing initial support for Jwt-Encoded Bearer Token authorization
with remote JWK set signature verification.
High-level features include:
- Accepting bearer tokens as headers and form or query parameters
- Verifying signatures from a remote Jwk set
And:
- A DSL for easy configuration
- A sample to demonstrate usage
Fixes: gh-5128
Fixes: gh-5125
Fixes: gh-5121
Fixes: gh-5130
Fixes: gh-5226
Fixes: gh-5237
This introduces the capability for users to wire denial handling
by request matcher, similar to how users can already do with
authentication entry points.
This is handy for when denial behavior differs based on the contents
of the request, for example, when the Authorization header indicates
an OAuth2 Bearer Token request vs Basic authentication.
Fixes: gh-5478
This introduces an evolution on CsrfConfigurer#ignoreAntMatchers,
allowing users to specify a RequestMatcher in the circumstance where
more than just the path needs to be analyzed to determine whether
CsrfFilter should require a token for the request.
Simply put, a user can now selectively disable csrf by request matcher
in addition to the way it can already be done with ant matchers.
Fixes: gh-5477
Other configurers can now offer their preference on session creation
policy without trumping what a user provided via the
sessionCreationPolicy method.
This is valuable for configurer's like Resource Server that would like
to have session management be stateless, but not at the expense of the
user's direct configuration.
Fixes: gh-5518
This commit introduces support for transient authentication tokens
which indicate to the filter chain, specifically the
HttpSessionSecurityContextRepository, whether or not the token ought
to be persisted across requests.
To leverage this, simply annotate any Authentication implementation
with @TransientAuthentication, extend from an Authentication that uses
this annotation, or annotate a custom annotation.
Implementations of SecurityContextRepository may choose to not persist
tokens that are marked with @TransientAuthentication in the same way
that HttpSessionSecurityContextRepository does.
Fixes: gh-5481
Java Config http.oauth2Login().loginProcessingUrl("url"); throws NPE.
Override loginProcessingUrl method and cached config url.
Then when the config is initialized,
it calls the super method to complete the configuration.
Fixes gh-5488
HstsSpec methods maxAge and includeSubdomains use to return void
which broke using it as a fluent API.
The methods now return HstsSpec which fixes this issue.
Fixes: gh-5483
Also, slightly modified the approach when asserting headers. In the
previous incarnation, the tests would assert an exact match against
the list of headers, which is more brittle than confirming that the
expected headers are there and the unexpected ones are not.
Now, should Spring Security add other headers that are outside the
purview of the secure headers configuration, the assertions won't
break.
Issue: gh-4939
This reverts commit 9fe0f50e3c.
The original commit was accidentally pushed prior to PR. We attempted
to revert the commit hoping the PR would open again. This did not work.
We are going to do a Polish commit instead.
Issue: gh-5355
Groovy has more extensive support for Xml parsing via XmlSlurper.
To replace it, this conversion also introduces a SAX wrapper,
NicerXmlParser, and a companion Node wrapper, NicerNode, that
allowed for less modification of the converted tests.
Issue: gh-4939
Note that the `WhenUsingAspectJ` tests are still simply verifying structure instead of behavior. This is because the project appearsto be misconfigured in some way such that AspectJ advice isn't getting woven in at runtime. The original Groovy tests also only verified structure and they may be that way for a similar reason.
Either way, I will open up a ticket so we can review why that is the case and if there is a good fix.
Issue: gh-4939
Note that the old groovy test used a configuration of
```
http
.authorizeRequests()
.anyRequest().hasAnyAuthority("USER")
```
However, as I read the issue, gh-2984, the problem this issue
identifies is the non-passive change of defaulting to prefix
ROLE_ with all role-based configuration methods. So, the test now
does the following:
```
http
.authorizeRequests()
.anyRequest().access("hasAnyRole('USER')")
```
which demonstrates, given the configuration in this test, that
ROLE_ is correctly not prefixed in this expression, even though
it is a role-based configuration.
Issue: gh-4939
All tests in `org.springframework.security.config.debug` are migrated.
Note that `SecurityDebugBeanFactoryPostProceessorTest` preserves the original structure-verifying strategy used in the Groovy test. Verifying debug behavior turns out to be fairly tricky since being behaviorally invisible is in its nature.
Issue: gh-4939
Rob Winch
Josh Cummings
Joe Grandja
Eric Hudon
Jonathan Chen
mhyeon.lee
Johnny Lim
Mahan Hashemizadeh
Kazuki Shimizu
Denys Ivano
Christoph Dreis