Cwikius-Spring/spring-security
1
0
Fork 0
mirror of https://github.com/spring-projects/spring-security.git synced 2025-06-23 20:42:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch '6.3.x'

Browse Source
This commit is contained in:
Josh Cummings 2024-08-26 16:33:04 -06:00
commit d2e8c19789
No known key found for this signature in database
GPG Key ID: A306A51F43B8E5A5
3 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
config/src/test/java/org/springframework/security/config/annotation/web/configurers/oauth2/client/OAuth2LoginConfigurerTests.java
View File

@ -650,7 +650,7 @@ public class OAuth2LoginConfigurerTests {
} }
@Test @Test
public void configureWhenOidcSessionStrategyThenUses() { public void configureWhenOidcSessionRegistryThenUses() {
this.spring.register(OAuth2LoginWithOidcSessionRegistry.class).autowire(); this.spring.register(OAuth2LoginWithOidcSessionRegistry.class).autowire();
OidcSessionRegistry registry = this.spring.getContext().getBean(OidcSessionRegistry.class); OidcSessionRegistry registry = this.spring.getContext().getBean(OidcSessionRegistry.class);
this.spring.getContext().publishEvent(new HttpSessionDestroyedEvent(this.request.getSession())); this.spring.getContext().publishEvent(new HttpSessionDestroyedEvent(this.request.getSession()));

18
docs/modules/ROOT/pages/reactive/oauth2/login/logout.adoc
View File

@ -187,7 +187,7 @@ Consider a `ClientRegistration` whose identifier is `registrationId`.
The overall flow for a Back-Channel logout is like this: The overall flow for a Back-Channel logout is like this:
1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `ReactiveOidcSessionStrategy` implementation. 1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `ReactiveOidcSessionRegistry` implementation.
2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout. 2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
3. Spring Security validates the token's signature and claims. 3. Spring Security validates the token's signature and claims.
4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated. 4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
@ -197,13 +197,13 @@ The overall flow for a Back-Channel logout is like this:
Remember that Spring Security's OIDC support is multi-tenant. Remember that Spring Security's OIDC support is multi-tenant.
This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token. This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.
=== Customizing the OIDC Provider Session Strategy === Customizing the OIDC Provider Session Registry
By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session. By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.
There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database. There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.
You can achieve this by configuring a custom `ReactiveOidcSessionStrategy`, like so: You can achieve this by configuring a custom `ReactiveOidcSessionRegistry`, like so:
[tabs] [tabs]
====== ======
@ -212,23 +212,23 @@ Java::
[source,java,role="primary"] [source,java,role="primary"]
---- ----
@Component @Component
public final class MySpringDataOidcSessionStrategy implements OidcSessionStrategy { public final class MySpringDataOidcSessionRegistry implements ReactiveOidcSessionRegistry {
private final OidcProviderSessionRepository sessions; private final OidcProviderSessionRepository sessions;
// ... // ...
@Override @Override
public void saveSessionInformation(OidcSessionInformation info) { public Mono<void> saveSessionInformation(OidcSessionInformation info) {
this.sessions.save(info); return this.sessions.save(info);
} }
@Override @Override
public OidcSessionInformation(String clientSessionId) { public Mono<OidcSessionInformation> removeSessionInformation(String clientSessionId) {
return this.sessions.removeByClientSessionId(clientSessionId); return this.sessions.removeByClientSessionId(clientSessionId);
} }
@Override @Override
public Iterable<OidcSessionInformation> removeSessionInformation(OidcLogoutToken token) { public Flux<OidcSessionInformation> removeSessionInformation(OidcLogoutToken token) {
return token.getSessionId() != null ? return token.getSessionId() != null ?
this.sessions.removeBySessionIdAndIssuerAndAudience(...) : this.sessions.removeBySessionIdAndIssuerAndAudience(...) :
this.sessions.removeBySubjectAndIssuerAndAudience(...); this.sessions.removeBySubjectAndIssuerAndAudience(...);
@ -241,7 +241,7 @@ Kotlin::
[source,kotlin,role="secondary"] [source,kotlin,role="secondary"]
---- ----
@Component @Component
class MySpringDataOidcSessionStrategy: ReactiveOidcSessionStrategy { class MySpringDataOidcSessionRegistry: ReactiveOidcSessionRegistry {
val sessions: OidcProviderSessionRepository val sessions: OidcProviderSessionRepository
// ... // ...

12
docs/modules/ROOT/pages/servlet/oauth2/login/logout.adoc
View File

@ -213,7 +213,7 @@ Consider a `ClientRegistration` whose identifier is `registrationId`.
The overall flow for a Back-Channel logout is like this: The overall flow for a Back-Channel logout is like this:
1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `OidcSessionStrategy` implementation. 1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `OidcSessionRegistry` implementation.
2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout. 2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
3. Spring Security validates the token's signature and claims. 3. Spring Security validates the token's signature and claims.
4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated. 4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
@ -223,13 +223,13 @@ The overall flow for a Back-Channel logout is like this:
Remember that Spring Security's OIDC support is multi-tenant. Remember that Spring Security's OIDC support is multi-tenant.
This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token. This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.
=== Customizing the OIDC Provider Session Strategy === Customizing the OIDC Provider Session Registry
By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session. By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.
There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database. There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.
You can achieve this by configuring a custom `OidcSessionStrategy`, like so: You can achieve this by configuring a custom `OidcSessionRegistry`, like so:
[tabs] [tabs]
====== ======
@ -238,7 +238,7 @@ Java::
[source,java,role="primary"] [source,java,role="primary"]
---- ----
@Component @Component
public final class MySpringDataOidcSessionStrategy implements OidcSessionStrategy { public final class MySpringDataOidcSessionRegistry implements OidcSessionRegistry {
private final OidcProviderSessionRepository sessions; private final OidcProviderSessionRepository sessions;
// ... // ...
@ -249,7 +249,7 @@ public final class MySpringDataOidcSessionStrategy implements OidcSessionStrateg
} }
@Override @Override
public OidcSessionInformation(String clientSessionId) { public OidcSessionInformation removeSessionInformation(String clientSessionId) {
return this.sessions.removeByClientSessionId(clientSessionId); return this.sessions.removeByClientSessionId(clientSessionId);
} }
@ -267,7 +267,7 @@ Kotlin::
[source,kotlin,role="secondary"] [source,kotlin,role="secondary"]
---- ----
@Component @Component
class MySpringDataOidcSessionStrategy: OidcSessionStrategy { class MySpringDataOidcSessionRegistry: OidcSessionRegistry {
val sessions: OidcProviderSessionRepository val sessions: OidcProviderSessionRepository
// ... // ...