`AclEntryVoter`, `AclEntryAfterInvocationProvider`, and `AclPermissionEvaluator` provide the same service, plugged into different Spring Security APIs. Now that `AccessDecisionVoter` and `AfterInvocationProvider` are both deprecated, the corresponding ACL plugins are obsolete.
As such, begin using `AclPermissionEvaluator` before updating to Spring Security 7.
== Opaque Token Credentials Will Be Encoded For You
In order to comply more closely with the Introspection RFC, Spring Security's opaque token support will encode the client id and secret before creating the authorization header.
This change means you will no longer have to encode the client id and secret yourself.
If your client id or secret contain URL-unsafe characters, then you can prepare yourself for this change by doing the following:
=== Replace Usage of `introspectionClientCredentials`
Since Spring Security can now do the encoding for you, replace xref:servlet/oauth2/resource-server/opaque-token.adoc#oauth2resourceserver-opaque-introspectionuri-dsl[using `introspectionClientCredentials`] with publishing the following `@Bean`:
@ -22,3 +22,82 @@ public void doSomething(Long id) {
@@ -22,3 +22,82 @@ public void doSomething(Long id) {
You must compile with `-parameters` to ensure that the parameter names are available at runtime.
For more information about this, please visit the https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x#core-container[Upgrading to Spring Framework 6.1 page].
=== Favor `AnnotationTemplateExpressionDefaults` over `PrePostTemplateDefaults`
In Spring Security 7, `AnnotationTemplateExpressionDefaults` will be included by default.
If you are customizing `PrePostTemplateDefaults` or simply want to see how your application responds to `AnnotationTemplateExpressionDefaults`, you can publish an `AnnotationTemplateExpressionDefaults` bean instead of a `PrePostTemplateDefaults` method:
If you are publishing an `AuthorizationAdvisor` bean, like `AuthorizationManagerBeforeMethodInterceptor`, `AuthorizationManagerAfterMethodInterceptor`, `PreFilterAuthorizationMethodInterceptor`, or `PostFilterAuthorizationMethodInterceptor`, you can do the same by calling `setTemplateDefaults` with an `AnnotationTemplateExpressionDefaults` instance instead:
[tabs]
======
Java::
+
[source,java,role="primary"]
----
@Bean
@Role(BeanDescription.ROLE_INFRASTRUCTURE)
static Advisor preFilter() {
PreFilterAuthorizationMethodInterceptor interceptor = new PreFilterAuthorizationMethodInterceptor();
=== Publish `AuthorizationAdvisor` instances instead of adding them in a `Customizer<AuthorizationAdvisorProxyFactory>`
While the ability to customize the `AuthorizationAdvisorProxyFactory` instance will remain in Spring Security 7, the ability to add advisors will be removed in favor of picking up published `AuthorizationAdvisor` beans.
If you are not calling `AuthorizationAdvisorProxyFactory#setAdvisors` or `AuthorizationAdvisorProxyFactory#addAdvisor`, you need do nothing.
If you are, publish the `AuthorizationAdvisor` bean instead and Spring Security will pick it up and apply it automatically.
@ -123,3 +123,60 @@ In versions prior to 6.2, if you had a xref:servlet/configuration/java.adoc#jc-c
@@ -123,3 +123,60 @@ In versions prior to 6.2, if you had a xref:servlet/configuration/java.adoc#jc-c
However, starting from version 6.2, this method is deprecated and will be removed in 7.0 because it will no longer be possible to chain configurations using `.and()` once `.and()` is removed (see https://github.com/spring-projects/spring-security/issues/13067).
Instead, it is recommended to use the new `.with(...)` method.
For more information about how to use `.with(...)` please refer to the xref:servlet/configuration/java.adoc#jc-custom-dsls[Custom DSLs section].
== Use `dispatcherTypeMatchers` instead of `shouldFilterAllDispatcherTypes`
If you are permitting the ERROR dispatch, you may be using `shouldFilterAllDispatcherTypes(false)` in the `auhorizeHttpRequests` DSL:
[tabs]
======
Java::
+
[source,java,role="primary"]
----
http
.authorizeHttpRequests((authorize) -> authorize
.shouldFilterAllDispatcherTypes(false)
// ...
)
----
Kotlin::
+
[source,kotlin,role="secondary"]
----
http {
authorizeHttpRequests {
shouldFilterAllDispatcherTypes = false
// ...
}
}
----
======
In preparation for 7, change this to use `dispatcherTypeMatchers`:
@ -170,3 +170,70 @@ fun jwtDecoder(): JwtDecoder {
@@ -170,3 +170,70 @@ fun jwtDecoder(): JwtDecoder {
<2> - specify the list of validators you need, excluding `JwtTypeValidator`
For additional guidance, please see the xref:servlet/oauth2/resource-server/jwt.adoc#oauth2resourceserver-jwt-validation[JwtDecoder Validators] section in the reference.
== Opaque Token Credentials Will Be Encoded For You
In order to comply more closely with the Introspection RFC, Spring Security's opaque token support will encode the client id and secret before creating the authorization header.
This change means you will no longer have to encode the client id and secret yourself.
If your client id or secret contain URL-unsafe characters, then you can prepare yourself for this change by doing the following:
=== Replace Usage of `introspectionClientCredentials`
Since Spring Security can now do the encoding for you, replace xref:servlet/oauth2/resource-server/opaque-token.adoc#oauth2resourceserver-opaque-introspectionuri-dsl[using `introspectionClientCredentials`] with publishing the following `@Bean`:
OpenSAML 4.x is no longer supported by the OpenSAML team.
As such, Spring Security will default to using its `OpenSaml5` components in all cases.
If you want to see how well your application will respond to this, do the following:
1. Update your OpenSAML dependencies to 5.x
2. If you are constructing an `OpenSaml4XXX` Spring Security component, change it to `OpenSaml5`.
If you cannot opt-in, then add the `opensaml-saml-api` and `opensaml-saml-impl` 4.x dependencies and exclude the 5.x dependencies from `spring-security-saml2-service-provider`.
== Continue Filter Chain When No Relying Party Found
In Spring Security 6, `Saml2WebSsoAuthenticationFilter` throws an exception when the request URI matches, but no relying party registration is found.
If you have several circumstances where HTTP is needed, consider using `OrRequestMatcher` to combine them into a single `RequestMatcher` instance.
=====
== Use `setCookieCustomizer` instead of individual setters
In favor of a simpler API, `CookieCsrfTokenRepository#setCookieCustomizer` allows you to change any aspect of the cookie, replacing `setCookieHttpOnly`, `setCookieMaxAge`, `setSecure`, and `setCookieDomain`.