diff --git a/docs/modules/ROOT/pages/servlet/architecture.adoc b/docs/modules/ROOT/pages/servlet/architecture.adoc index 01139c110d..e0f6e04925 100644 --- a/docs/modules/ROOT/pages/servlet/architecture.adoc +++ b/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 <> in `SecurityFilterChain` are typically Beans, but they are registered with `FilterChainProxy` instead of <>. @@ -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 <> figure, `FilterChainProxy` decides which `SecurityFilterChain` should be used. @@ -398,6 +403,7 @@ The {security-api-url}org/springframework/security/web/access/ExceptionTranslati The following image shows the relationship of `ExceptionTranslationFilter` to other components: +[.invert-dark] image::{figures}/exceptiontranslationfilter.png[] diff --git a/docs/modules/ROOT/pages/servlet/authentication/architecture.adoc b/docs/modules/ROOT/pages/servlet/authentication/architecture.adoc index 725fd46d7e..51bdbb8b7a 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/architecture.adoc +++ b/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 <>. +[.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 @@ While the implementation of `AuthenticationManager` could be anything, the most 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]] @@ -234,6 +238,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 <> from the `HttpServletRequest` to be authenticated. diff --git a/docs/modules/ROOT/pages/servlet/authentication/passwords/basic.adoc b/docs/modules/ROOT/pages/servlet/authentication/passwords/basic.adoc index aeecd5e60b..3ff7ed6d65 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/passwords/basic.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/servlet/authentication/passwords/dao-authentication-provider.adoc b/docs/modules/ROOT/pages/servlet/authentication/passwords/dao-authentication-provider.adoc index 1366308c7c..f49edade74 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/passwords/dao-authentication-provider.adoc +++ b/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`]. diff --git a/docs/modules/ROOT/pages/servlet/authentication/passwords/form.adoc b/docs/modules/ROOT/pages/servlet/authentication/passwords/form.adoc index 91f211e3e6..c80e140712 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/passwords/form.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/servlet/authentication/persistence.adoc b/docs/modules/ROOT/pages/servlet/authentication/persistence.adoc index 1528d66787..3f214cd1e6 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/persistence.adoc +++ b/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 {security-api-url}org/springframework/security/web/context/SecurityContextPersistenceFilter.html[`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`. @@ -212,6 +213,7 @@ To avoid these problems, the `SecurityContextPersistenceFilter` wraps both the ` The {security-api-url}org/springframework/security/web/context/SecurityContextHolderFilter.html[`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`. diff --git a/docs/modules/ROOT/pages/servlet/authorization/architecture.adoc b/docs/modules/ROOT/pages/servlet/authorization/architecture.adoc index d8a910610b..e2d5aeef68 100644 --- a/docs/modules/ROOT/pages/servlet/authorization/architecture.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/servlet/authorization/authorize-http-requests.adoc b/docs/modules/ROOT/pages/servlet/authorization/authorize-http-requests.adoc index 0e46caaf46..5fd01b2a09 100644 --- a/docs/modules/ROOT/pages/servlet/authorization/authorize-http-requests.adoc +++ b/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]. diff --git a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/index.adoc b/docs/modules/ROOT/pages/servlet/oauth2/resource-server/index.adoc index 3a3eae8ea7..415a7bf283 100644 --- a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/index.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/jwt.adoc b/docs/modules/ROOT/pages/servlet/oauth2/resource-server/jwt.adoc index b800953278..801f2ce8a1 100644 --- a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/jwt.adoc +++ b/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`]. diff --git a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/opaque-token.adoc b/docs/modules/ROOT/pages/servlet/oauth2/resource-server/opaque-token.adoc index eaa3e5cfd3..82968028a7 100644 --- a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/opaque-token.adoc +++ b/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`]. diff --git a/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc b/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc index 7b44f2ed8c..396edb8bd2 100644 --- a/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc +++ b/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc @@ -7,6 +7,7 @@ First, we see that, like <>, 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 `` [[servlet-saml2login-authentication-saml2webssoauthenticationfilter]] .Authenticating a `` +[.invert-dark] image::{figures}/saml2webssoauthenticationfilter.png[] [NOTE]