Merge branch '6.3.x'

docs/modules/ROOT/pages/servlet/architecture.adoc

@@ -14,6 +14,7 @@ The following image shows the typical layering of the handlers for a single HTTP
 
 .FilterChain
 [[servlet-filterchain-figure]]
+[.invert-dark]
 image::{figures}/filterchain.png[]
 
 The client sends a request to the application, and the container creates a `FilterChain`, which contains the `Filter` instances and `Servlet` that should process the `HttpServletRequest`, based on the path of the request URI.
@@ -66,6 +67,7 @@ Here is a picture of how `DelegatingFilterProxy` fits into the <<servlet-filters
 
 .DelegatingFilterProxy
 [[servlet-delegatingfilterproxy-figure]]
+[.invert-dark]
 image::{figures}/delegatingfilterproxy.png[]
 
 `DelegatingFilterProxy` looks up __Bean Filter~0~__ from the `ApplicationContext` and then invokes __Bean Filter~0~__.
@@ -113,6 +115,7 @@ The following image shows the role of `FilterChainProxy`.
 
 .FilterChainProxy
 [[servlet-filterchainproxy-figure]]
+[.invert-dark]
 image::{figures}/filterchainproxy.png[]
 
 [[servlet-securityfilterchain]]
@@ -124,6 +127,7 @@ The following image shows the role of `SecurityFilterChain`.
 
 .SecurityFilterChain
 [[servlet-securityfilterchain-figure]]
+[.invert-dark]
 image::{figures}/securityfilterchain.png[]
 
 The <<servlet-security-filters,Security Filters>> in `SecurityFilterChain` are typically Beans, but they are registered with `FilterChainProxy` instead of <<servlet-delegatingfilterproxy>>.
@@ -145,6 +149,7 @@ The following image shows multiple `SecurityFilterChain` instances:
 
 .Multiple SecurityFilterChain
 [[servlet-multi-securityfilterchain-figure]]
+[.invert-dark]
 image::{figures}/multi-securityfilterchain.png[]
 
 In the <<servlet-multi-securityfilterchain-figure>> figure, `FilterChainProxy` decides which `SecurityFilterChain` should be used.
@@ -567,6 +572,7 @@ The javadoc:org.springframework.security.web.access.ExceptionTranslationFilter[]
 
 The following image shows the relationship of `ExceptionTranslationFilter` to other components:
 
+[.invert-dark]
 image::{figures}/exceptiontranslationfilter.png[]
 
 

docs/modules/ROOT/pages/servlet/authentication/architecture.adoc

@@ -22,6 +22,7 @@ This also gives a good idea of the high level flow of authentication and how pie
 At the heart of Spring Security's authentication model is the `SecurityContextHolder`.
 It contains the <<servlet-authentication-securitycontext>>.
 
+[.invert-dark]
 image::{figures}/securitycontextholder.png[]
 
 The `SecurityContextHolder` is where Spring Security stores the details of who is xref:features/authentication/index.adoc#authentication[authenticated].
@@ -175,6 +176,7 @@ javadoc:org.springframework.security.authentication.ProviderManager[] is the mos
 Each `AuthenticationProvider` has an opportunity to indicate that authentication should be successful, fail, or indicate it cannot make a decision and allow a downstream `AuthenticationProvider` to decide.
 If none of the configured `AuthenticationProvider` instances can authenticate, authentication fails with a `ProviderNotFoundException`, which is a special `AuthenticationException` that indicates that the `ProviderManager` was not configured to support the type of `Authentication` that was passed into it.
 
+[.invert-dark]
 image::{figures}/providermanager.png[]
 
 In practice each `AuthenticationProvider` knows how to perform a specific type of authentication.
@@ -184,11 +186,13 @@ This lets each `AuthenticationProvider` do a very specific type of authenticatio
 `ProviderManager` also allows configuring an optional parent `AuthenticationManager`, which is consulted in the event that no `AuthenticationProvider` can perform authentication.
 The parent can be any type of `AuthenticationManager`, but it is often an instance of `ProviderManager`.
 
+[.invert-dark]
 image::{figures}/providermanager-parent.png[]
 
 In fact, multiple `ProviderManager` instances might share the same parent `AuthenticationManager`.
 This is somewhat common in scenarios where there are multiple xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] instances that have some authentication in common (the shared parent `AuthenticationManager`), but also different authentication mechanisms (the different `ProviderManager` instances).
 
+[.invert-dark]
 image::{figures}/providermanagers-parent.png[]
 
 [[servlet-authentication-providermanager-erasing-credentials]]
@@ -240,6 +244,7 @@ Before the credentials can be authenticated, Spring Security typically requests
 
 Next, the `AbstractAuthenticationProcessingFilter` can authenticate any authentication requests that are submitted to it.
 
+[.invert-dark]
 image::{figures}/abstractauthenticationprocessingfilter.png[]
 
 image:{icondir}/number_1.png[] When the user submits their credentials, the `AbstractAuthenticationProcessingFilter` creates an <<servlet-authentication-authentication,`Authentication`>> from the `HttpServletRequest` to be authenticated.

docs/modules/ROOT/pages/servlet/authentication/passwords/basic.adoc

@@ -9,6 +9,7 @@ This section describes how HTTP Basic Authentication works within Spring Securit
 First, we see the https://tools.ietf.org/html/rfc7235#section-4.1[WWW-Authenticate] header is sent back to an unauthenticated client:
 
 .Sending WWW-Authenticate Header
+[.invert-dark]
 image::{figures}/basicauthenticationentrypoint.png[]
 
 The preceding figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.
@@ -26,6 +27,7 @@ The following image shows the flow for the username and password being processed
 
 [[servlet-authentication-basicauthenticationfilter]]
 .Authenticating Username and Password
+[.invert-dark]
 image::{figures}/basicauthenticationfilter.png[]
 
 The preceding figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.

docs/modules/ROOT/pages/servlet/authentication/passwords/dao-authentication-provider.adoc

@@ -8,6 +8,7 @@ This section examines how `DaoAuthenticationProvider` works within Spring Securi
 The following figure explains the workings of the xref:servlet/authentication/architecture.adoc#servlet-authentication-authenticationmanager[`AuthenticationManager`] in figures from the xref:servlet/authentication/passwords/index.adoc#servlet-authentication-unpwd-input[Reading the Username & Password] section.
 
 .`DaoAuthenticationProvider` Usage
+[.invert-dark]
 image::{figures}/daoauthenticationprovider.png[]
 
 image:{icondir}/number_1.png[] The authentication `Filter` from the xref:servlet/authentication/passwords/index.adoc#servlet-authentication-unpwd-input[Reading the Username & Password] section passes a `UsernamePasswordAuthenticationToken` to the `AuthenticationManager`, which is implemented by xref:servlet/authentication/architecture.adoc#servlet-authentication-providermanager[`ProviderManager`].

docs/modules/ROOT/pages/servlet/authentication/passwords/form.adoc

@@ -10,6 +10,7 @@ This section examines how form-based login works within Spring Security.
 First, we see how the user is redirected to the login form:
 
 .Redirecting to the Login Page
+[.invert-dark]
 image::{figures}/loginurlauthenticationentrypoint.png[]
 
 The preceding figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.
@@ -30,6 +31,7 @@ When the username and password are submitted, the `UsernamePasswordAuthenticatio
 The `UsernamePasswordAuthenticationFilter` extends xref:servlet/authentication/architecture.adoc#servlet-authentication-abstractprocessingfilter[AbstractAuthenticationProcessingFilter], so the following diagram should look pretty similar:
 
 .Authenticating Username and Password
+[.invert-dark]
 image::{figures}/usernamepasswordauthenticationfilter.png[]
 
 The figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.

docs/modules/ROOT/pages/servlet/authentication/persistence.adoc

@@ -191,6 +191,7 @@ In Spring Security 6, the example shown above is the default configuration.
 
 The javadoc:org.springframework.security.web.context.SecurityContextPersistenceFilter[] is responsible for persisting the `SecurityContext` between requests using the xref::servlet/authentication/persistence.adoc#securitycontextrepository[`SecurityContextRepository`].
 
+[.invert-dark]
 image::{figures}/securitycontextpersistencefilter.png[]
 
 image:{icondir}/number_1.png[] Before running the rest of the application, `SecurityContextPersistenceFilter` loads the `SecurityContext` from the `SecurityContextRepository` and sets it on the `SecurityContextHolder`.
@@ -213,6 +214,7 @@ To avoid these problems, the `SecurityContextPersistenceFilter` wraps both the `
 
 The javadoc:org.springframework.security.web.context.SecurityContextHolderFilter[] is responsible for loading the `SecurityContext` between requests using the xref::servlet/authentication/persistence.adoc#securitycontextrepository[`SecurityContextRepository`].
 
+[.invert-dark]
 image::{figures}/securitycontextholderfilter.png[]
 
 image:{icondir}/number_1.png[] Before running the rest of the application, `SecurityContextHolderFilter` loads the `SecurityContext` from the `SecurityContextRepository` and sets it on the `SecurityContextHolder`.

docs/modules/ROOT/pages/servlet/authorization/architecture.adoc

@@ -126,6 +126,7 @@ For method security, you can use `AuthorizationManagerBeforeMethodInterceptor` a
 
 [[authz-authorization-manager-implementations]]
 .Authorization Manager Implementations
+[.invert-dark]
 image::{figures}/authorizationhierarchy.png[]
 
 Using this approach, a composition of `AuthorizationManager` implementations can be polled on an authorization decision.
@@ -342,6 +343,7 @@ The following image shows the `AccessDecisionManager` interface:
 
 [[authz-access-voting]]
 .Voting Decision Manager
+[.invert-dark]
 image::{figures}/access-decision-voting.png[]
 
 By using this approach, a series of `AccessDecisionVoter` implementations are polled on an authorization decision.
@@ -402,6 +404,7 @@ For example, on the Spring web site, you can find a https://spring.io/blog/2009/
 
 [[authz-after-invocation]]
 .After Invocation Implementation
+[.invert-dark]
 image::{figures}/after-invocation.png[]
 
 Like many other parts of Spring Security, `AfterInvocationManager` has a single concrete implementation, `AfterInvocationProviderManager`, which polls a list of ``AfterInvocationProvider``s.

docs/modules/ROOT/pages/servlet/authorization/authorize-http-requests.adoc

@@ -65,6 +65,7 @@ In many cases, your authorization rules will be more sophisticated than that, so
 This section builds on xref:servlet/architecture.adoc#servlet-architecture[Servlet Architecture and Implementation] by digging deeper into how xref:servlet/authorization/index.adoc#servlet-authorization[authorization] works at the request level in Servlet-based applications.
 
 .Authorize HttpServletRequest
+[.invert-dark]
 image::{figures}/authorizationfilter.png[]
 
 * image:{icondir}/number_1.png[] First, the `AuthorizationFilter` constructs a `Supplier` that retrieves an  xref:servlet/authentication/architecture.adoc#servlet-authentication-authentication[Authentication] from the xref:servlet/authentication/architecture.adoc#servlet-authentication-securitycontextholder[SecurityContextHolder].

docs/modules/ROOT/pages/servlet/oauth2/resource-server/index.adoc

@@ -21,6 +21,7 @@ Now we can consider how Bearer Token Authentication works within Spring Security
 First, we see that, as with xref:servlet/authentication/passwords/basic.adoc#servlet-authentication-basic[Basic Authentication], the https://tools.ietf.org/html/rfc7235#section-4.1[WWW-Authenticate] header is sent back to an unauthenticated client:
 
 .Sending WWW-Authenticate Header
+[.invert-dark]
 image::{figures}/bearerauthenticationentrypoint.png[]
 
 The figure above builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.
@@ -38,6 +39,7 @@ The following image shows the flow for the bearer token being processed:
 
 [[oauth2resourceserver-authentication-bearertokenauthenticationfilter]]
 .Authenticating Bearer Token
+[.invert-dark]
 image::{figures}/bearertokenauthenticationfilter.png[]
 
 The figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.

docs/modules/ROOT/pages/servlet/oauth2/resource-server/jwt.adoc

@@ -92,6 +92,7 @@ Let's take a look at how `JwtAuthenticationProvider` works within Spring Securit
 The figure explains details of how the xref:servlet/authentication/architecture.adoc#servlet-authentication-authenticationmanager[`AuthenticationManager`] in figures from xref:servlet/oauth2/resource-server/index.adoc#oauth2resourceserver-authentication-bearertokenauthenticationfilter[Reading the Bearer Token] works.
 
 .`JwtAuthenticationProvider` Usage
+[.invert-dark]
 image::{figures}/jwtauthenticationprovider.png[]
 
 image:{icondir}/number_1.png[] The authentication `Filter` from xref:servlet/oauth2/resource-server/index.adoc#oauth2resourceserver-authentication-bearertokenauthenticationfilter[Reading the Bearer Token] passes a `BearerTokenAuthenticationToken` to the `AuthenticationManager` which is implemented by xref:servlet/authentication/architecture.adoc#servlet-authentication-providermanager[`ProviderManager`].

docs/modules/ROOT/pages/servlet/oauth2/resource-server/opaque-token.adoc

@@ -88,6 +88,7 @@ Let's take a look at how `OpaqueTokenAuthenticationProvider` works within Spring
 The figure explains details of how the xref:servlet/authentication/architecture.adoc#servlet-authentication-authenticationmanager[`AuthenticationManager`] in figures from xref:servlet/oauth2/resource-server/index.adoc#oauth2resourceserver-authentication-bearertokenauthenticationfilter[Reading the Bearer Token] works.
 
 .`OpaqueTokenAuthenticationProvider` Usage
+[.invert-dark]
 image::{figures}/opaquetokenauthenticationprovider.png[]
 
 image:{icondir}/number_1.png[] The authentication `Filter` from xref:servlet/oauth2/resource-server/index.adoc#oauth2resourceserver-authentication-bearertokenauthenticationfilter[Reading the Bearer Token] passes a `BearerTokenAuthenticationToken` to the `AuthenticationManager` which is implemented by xref:servlet/authentication/architecture.adoc#servlet-authentication-providermanager[`ProviderManager`].

docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc

@@ -7,6 +7,7 @@ First, we see that, like <<oauth2login, OAuth 2.0 Login>>, Spring Security takes
 It does this through a series of redirects:
 
 .Redirecting to Asserting Party Authentication
+[.invert-dark]
 image::{figures}/saml2webssoauthenticationrequestfilter.png[]
 
 [NOTE]
@@ -34,6 +35,7 @@ The following image shows how Spring Security authenticates a `<saml2:Response>`
 
 [[servlet-saml2login-authentication-saml2webssoauthenticationfilter]]
 .Authenticating a `<saml2:Response>`
+[.invert-dark]
 image::{figures}/saml2webssoauthenticationfilter.png[]
 
 [NOTE]