parent
7881660ca0
commit
85248083c0
|
@ -14,6 +14,7 @@ The picture below shows the typical layering of the handlers for a single HTTP r
|
|||
|
||||
.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``s and `Servlet` that should process the `HttpServletRequest` based on the path of the request URI.
|
||||
|
@ -67,6 +68,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~__.
|
||||
|
@ -115,6 +117,7 @@ Since `FilterChainProxy` is a Bean, it is typically wrapped in a <<servlet-deleg
|
|||
|
||||
.FilterChainProxy
|
||||
[[servlet-filterchainproxy-figure]]
|
||||
[.invert-dark]
|
||||
image::{figures}/filterchainproxy.png[]
|
||||
|
||||
[[servlet-securityfilterchain]]
|
||||
|
@ -124,6 +127,7 @@ image::{figures}/filterchainproxy.png[]
|
|||
|
||||
.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>>.
|
||||
|
@ -146,6 +150,7 @@ This allows providing a totally separate configuration for different _slices_ of
|
|||
|
||||
.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.
|
||||
|
@ -391,6 +396,7 @@ The {security-api-url}org/springframework/security/web/access/ExceptionTranslati
|
|||
|
||||
`ExceptionTranslationFilter` is inserted into the <<servlet-filterchainproxy>> as one of the <<servlet-security-filters>>.
|
||||
|
||||
[.invert-dark]
|
||||
image::{figures}/exceptiontranslationfilter.png[]
|
||||
|
||||
|
||||
|
|
|
@ -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].
|
||||
|
@ -171,6 +172,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``s can authenticate, then authentication will fail with a `ProviderNotFoundException` which is a special `AuthenticationException` that indicates 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.
|
||||
|
@ -180,11 +182,13 @@ This allows each `AuthenticationProvider` to do a very specific type of authenti
|
|||
`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]]
|
||||
|
@ -230,6 +234,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.
|
||||
|
|
|
@ -9,6 +9,7 @@ Let's take a look at how HTTP Basic Authentication works within Spring Security.
|
|||
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 figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.
|
||||
|
@ -26,6 +27,7 @@ Below is the flow for the username and password being processed.
|
|||
|
||||
[[servlet-authentication-basicauthenticationfilter]]
|
||||
.Authenticating Username and Password
|
||||
[.invert-dark]
|
||||
image::{figures}/basicauthenticationfilter.png[]
|
||||
|
||||
The figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.
|
||||
|
|
|
@ -8,6 +8,7 @@ Let's take a look at how `DaoAuthenticationProvider` 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/authentication/passwords/index.adoc#servlet-authentication-unpwd-input[Reading the Username & Password] works.
|
||||
|
||||
.`DaoAuthenticationProvider` Usage
|
||||
[.invert-dark]
|
||||
image::{figures}/daoauthenticationprovider.png[]
|
||||
|
||||
image:{icondir}/number_1.png[] The authentication `Filter` from xref:servlet/authentication/passwords/index.adoc#servlet-authentication-unpwd-input[Reading the Username & Password] passes a `UsernamePasswordAuthenticationToken` to the `AuthenticationManager` which is implemented by xref:servlet/authentication/architecture.adoc#servlet-authentication-providermanager[`ProviderManager`].
|
||||
|
|
|
@ -10,6 +10,7 @@ Let's take a look at how form based log in works within Spring Security.
|
|||
First, we see how the user is redirected to the log in form.
|
||||
|
||||
.Redirecting to the Log In Page
|
||||
[.invert-dark]
|
||||
image::{figures}/loginurlauthenticationentrypoint.png[]
|
||||
|
||||
The 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 this 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.
|
||||
|
|
|
@ -187,6 +187,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`.
|
||||
|
@ -208,6 +209,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`.
|
||||
|
|
|
@ -73,6 +73,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.
|
||||
|
@ -271,6 +272,7 @@ Whilst users can implement their own `AccessDecisionManager` to control all aspe
|
|||
|
||||
[[authz-access-voting]]
|
||||
.Voting Decision Manager
|
||||
[.invert-dark]
|
||||
image::{figures}/access-decision-voting.png[]
|
||||
|
||||
Using this approach, a series of `AccessDecisionVoter` implementations are polled on an authorization decision.
|
||||
|
@ -330,6 +332,7 @@ For example, you'll find a https://spring.io/blog/2009/01/03/spring-security-cus
|
|||
|
||||
[[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.
|
||||
|
|
|
@ -46,6 +46,7 @@ Instead of the authentication needing to be looked up for every request, it will
|
|||
When `authorizeHttpRequests` is used instead of `authorizeRequests`, then {security-api-url}org/springframework/security/web/access/intercept/AuthorizationFilter.html[`AuthorizationFilter`] is used instead of xref:servlet/authorization/authorize-requests.adoc#servlet-authorization-filtersecurityinterceptor[`FilterSecurityInterceptor`].
|
||||
|
||||
.Authorize HttpServletRequest
|
||||
[.invert-dark]
|
||||
image::{figures}/authorizationfilter.png[]
|
||||
|
||||
* image:{icondir}/number_1.png[] First, the `AuthorizationFilter` obtains an xref:servlet/authentication/architecture.adoc#servlet-authentication-authentication[Authentication] from the xref:servlet/authentication/architecture.adoc#servlet-authentication-securitycontextholder[SecurityContextHolder].
|
||||
|
|
|
@ -12,6 +12,7 @@ The {security-api-url}org/springframework/security/web/access/intercept/FilterSe
|
|||
It is inserted into the xref:servlet/architecture.adoc#servlet-filterchainproxy[FilterChainProxy] as one of the xref:servlet/architecture.adoc#servlet-security-filters[Security Filters].
|
||||
|
||||
.Authorize HttpServletRequest
|
||||
[.invert-dark]
|
||||
image::{figures}/filtersecurityinterceptor.png[]
|
||||
|
||||
* image:{icondir}/number_1.png[] First, the `FilterSecurityInterceptor` obtains an xref:servlet/authentication/architecture.adoc#servlet-authentication-authentication[Authentication] from the xref:servlet/authentication/architecture.adoc#servlet-authentication-securitycontextholder[SecurityContextHolder].
|
||||
|
|
|
@ -21,6 +21,7 @@ Let's take a look at how Bearer Token Authentication works within Spring Securit
|
|||
First, we see that, like 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 @@ Below is 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.
|
||||
|
|
|
@ -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 <<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 <<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`].
|
||||
|
|
|
@ -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 <<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 <<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`].
|
||||
|
|
|
@ -7,6 +7,7 @@ First, we see that, like xref:servlet/oauth2/login/index.adoc[OAuth 2.0 Login],
|
|||
It does this through a series of redirects.
|
||||
|
||||
.Redirecting to Asserting Party Authentication
|
||||
[.invert-dark]
|
||||
image::{figures}/saml2webssoauthenticationrequestfilter.png[]
|
||||
|
||||
The figure above builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] and xref:servlet/authentication/architecture.adoc#servlet-authentication-abstractprocessingfilter[`AbstractAuthenticationProcessingFilter`] diagrams:
|
||||
|
@ -29,6 +30,7 @@ image:{icondir}/number_6.png[] The browser then POSTs the `<saml2:Response>` to
|
|||
|
||||
[[servlet-saml2login-authentication-saml2webssoauthenticationfilter]]
|
||||
.Authenticating a `<saml2:Response>`
|
||||
[.invert-dark]
|
||||
image::{figures}/saml2webssoauthenticationfilter.png[]
|
||||
|
||||
The figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.
|
||||
|
|
Loading…
Reference in New Issue