Skip to content

Commit 1414b88

Browse files
committed
Merge branch '6.2.x' into 6.3.x
2 parents a91433d + ba520db commit 1414b88

File tree

12 files changed

+28
-0
lines changed

12 files changed

+28
-0
lines changed

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

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,7 @@ The following image shows the typical layering of the handlers for a single HTTP
1414

1515
.FilterChain
1616
[[servlet-filterchain-figure]]
17+
[.invert-dark]
1718
image::{figures}/filterchain.png[]
1819

1920
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
6667

6768
.DelegatingFilterProxy
6869
[[servlet-delegatingfilterproxy-figure]]
70+
[.invert-dark]
6971
image::{figures}/delegatingfilterproxy.png[]
7072

7173
`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`.
113115

114116
.FilterChainProxy
115117
[[servlet-filterchainproxy-figure]]
118+
[.invert-dark]
116119
image::{figures}/filterchainproxy.png[]
117120

118121
[[servlet-securityfilterchain]]
@@ -124,6 +127,7 @@ The following image shows the role of `SecurityFilterChain`.
124127

125128
.SecurityFilterChain
126129
[[servlet-securityfilterchain-figure]]
130+
[.invert-dark]
127131
image::{figures}/securityfilterchain.png[]
128132

129133
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:
145149

146150
.Multiple SecurityFilterChain
147151
[[servlet-multi-securityfilterchain-figure]]
152+
[.invert-dark]
148153
image::{figures}/multi-securityfilterchain.png[]
149154

150155
In the <<servlet-multi-securityfilterchain-figure>> figure, `FilterChainProxy` decides which `SecurityFilterChain` should be used.
@@ -398,6 +403,7 @@ The {security-api-url}org/springframework/security/web/access/ExceptionTranslati
398403

399404
The following image shows the relationship of `ExceptionTranslationFilter` to other components:
400405

406+
[.invert-dark]
401407
image::{figures}/exceptiontranslationfilter.png[]
402408

403409

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

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,7 @@ This also gives a good idea of the high level flow of authentication and how pie
2222
At the heart of Spring Security's authentication model is the `SecurityContextHolder`.
2323
It contains the <<servlet-authentication-securitycontext>>.
2424

25+
[.invert-dark]
2526
image::{figures}/securitycontextholder.png[]
2627

2728
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
175176
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.
176177
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.
177178

179+
[.invert-dark]
178180
image::{figures}/providermanager.png[]
179181

180182
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
184186
`ProviderManager` also allows configuring an optional parent `AuthenticationManager`, which is consulted in the event that no `AuthenticationProvider` can perform authentication.
185187
The parent can be any type of `AuthenticationManager`, but it is often an instance of `ProviderManager`.
186188

189+
[.invert-dark]
187190
image::{figures}/providermanager-parent.png[]
188191

189192
In fact, multiple `ProviderManager` instances might share the same parent `AuthenticationManager`.
190193
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).
191194

195+
[.invert-dark]
192196
image::{figures}/providermanagers-parent.png[]
193197

194198
[[servlet-authentication-providermanager-erasing-credentials]]
@@ -234,6 +238,7 @@ Before the credentials can be authenticated, Spring Security typically requests
234238

235239
Next, the `AbstractAuthenticationProcessingFilter` can authenticate any authentication requests that are submitted to it.
236240

241+
[.invert-dark]
237242
image::{figures}/abstractauthenticationprocessingfilter.png[]
238243

239244
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

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@ This section describes how HTTP Basic Authentication works within Spring Securit
99
First, we see the https://tools.ietf.org/html/rfc7235#section-4.1[WWW-Authenticate] header is sent back to an unauthenticated client:
1010

1111
.Sending WWW-Authenticate Header
12+
[.invert-dark]
1213
image::{figures}/basicauthenticationentrypoint.png[]
1314

1415
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
2627

2728
[[servlet-authentication-basicauthenticationfilter]]
2829
.Authenticating Username and Password
30+
[.invert-dark]
2931
image::{figures}/basicauthenticationfilter.png[]
3032

3133
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

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,7 @@ This section examines how `DaoAuthenticationProvider` works within Spring Securi
88
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.
99

1010
.`DaoAuthenticationProvider` Usage
11+
[.invert-dark]
1112
image::{figures}/daoauthenticationprovider.png[]
1213

1314
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

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@ This section examines how form-based login works within Spring Security.
1010
First, we see how the user is redirected to the login form:
1111

1212
.Redirecting to the Login Page
13+
[.invert-dark]
1314
image::{figures}/loginurlauthenticationentrypoint.png[]
1415

1516
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
3031
The `UsernamePasswordAuthenticationFilter` extends xref:servlet/authentication/architecture.adoc#servlet-authentication-abstractprocessingfilter[AbstractAuthenticationProcessingFilter], so the following diagram should look pretty similar:
3132

3233
.Authenticating Username and Password
34+
[.invert-dark]
3335
image::{figures}/usernamepasswordauthenticationfilter.png[]
3436

3537
The figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.

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

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -191,6 +191,7 @@ In Spring Security 6, the example shown above is the default configuration.
191191

192192
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`].
193193

194+
[.invert-dark]
194195
image::{figures}/securitycontextpersistencefilter.png[]
195196

196197
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 `
212213

213214
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`].
214215

216+
[.invert-dark]
215217
image::{figures}/securitycontextholderfilter.png[]
216218

217219
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

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -126,6 +126,7 @@ For method security, you can use `AuthorizationManagerBeforeMethodInterceptor` a
126126

127127
[[authz-authorization-manager-implementations]]
128128
.Authorization Manager Implementations
129+
[.invert-dark]
129130
image::{figures}/authorizationhierarchy.png[]
130131

131132
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:
342343

343344
[[authz-access-voting]]
344345
.Voting Decision Manager
346+
[.invert-dark]
345347
image::{figures}/access-decision-voting.png[]
346348

347349
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/
402404

403405
[[authz-after-invocation]]
404406
.After Invocation Implementation
407+
[.invert-dark]
405408
image::{figures}/after-invocation.png[]
406409

407410
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

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -65,6 +65,7 @@ In many cases, your authorization rules will be more sophisticated than that, so
6565
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.
6666

6767
.Authorize HttpServletRequest
68+
[.invert-dark]
6869
image::{figures}/authorizationfilter.png[]
6970

7071
* 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

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,7 @@ Now we can consider how Bearer Token Authentication works within Spring Security
2121
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:
2222

2323
.Sending WWW-Authenticate Header
24+
[.invert-dark]
2425
image::{figures}/bearerauthenticationentrypoint.png[]
2526

2627
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:
3839

3940
[[oauth2resourceserver-authentication-bearertokenauthenticationfilter]]
4041
.Authenticating Bearer Token
42+
[.invert-dark]
4143
image::{figures}/bearertokenauthenticationfilter.png[]
4244

4345
The figure builds off our xref:servlet/architecture.adoc#servlet-securityfilterchain[`SecurityFilterChain`] diagram.

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

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -92,6 +92,7 @@ Let's take a look at how `JwtAuthenticationProvider` works within Spring Securit
9292
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.
9393

9494
.`JwtAuthenticationProvider` Usage
95+
[.invert-dark]
9596
image::{figures}/jwtauthenticationprovider.png[]
9697

9798
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

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -88,6 +88,7 @@ Let's take a look at how `OpaqueTokenAuthenticationProvider` works within Spring
8888
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.
8989

9090
.`OpaqueTokenAuthenticationProvider` Usage
91+
[.invert-dark]
9192
image::{figures}/opaquetokenauthenticationprovider.png[]
9293

9394
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

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,7 @@ First, we see that, like <<oauth2login, OAuth 2.0 Login>>, Spring Security takes
77
It does this through a series of redirects:
88

99
.Redirecting to Asserting Party Authentication
10+
[.invert-dark]
1011
image::{figures}/saml2webssoauthenticationrequestfilter.png[]
1112

1213
[NOTE]
@@ -34,6 +35,7 @@ The following image shows how Spring Security authenticates a `<saml2:Response>`
3435

3536
[[servlet-saml2login-authentication-saml2webssoauthenticationfilter]]
3637
.Authenticating a `<saml2:Response>`
38+
[.invert-dark]
3739
image::{figures}/saml2webssoauthenticationfilter.png[]
3840

3941
[NOTE]

0 commit comments

Comments
 (0)