root
/
spring-security
mirror of https://github.com/spring-projects/spring-security.git
1
0
Fork 0
Code Issues Actions 6 Packages Projects Releases Wiki Activity

Fix inline code formatting in documentation
CI / Build (17, ubuntu-latest) (push) Waiting to run Details
CI / Build (17, windows-latest) (push) Waiting to run Details
CI / Test Against Snapshots (17, 17) (push) Waiting to run Details
CI / Test Against Snapshots (21-ea, 21) (push) Waiting to run Details
CI / Check Samples (push) Waiting to run Details
CI / Deploy Artifacts (push) Blocked by required conditions Details
CI / Deploy Docs (push) Blocked by required conditions Details
CI / Deploy Schema (push) Blocked by required conditions Details
CI / Perform Release (push) Blocked by required conditions Details
CI / Send Notification (push) Blocked by required conditions Details
Deploy Docs / build (push) Waiting to run Details 

Signed-off-by: Hao <kyrieeeee2@gmail.com>
This commit is contained in:
Hao 2025-03-11 15:15:27 +08:00 committed by Josh Cummings
parent 8c7d2e8922
commit 6159e089d4
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/modules/ROOT/pages/servlet/oauth2/resource-server/multitenancy.adoc
View File

@ -320,7 +320,7 @@ class TenantJWSKeySelector(tenants: TenantRepository) : JWTClaimsSetAwareJWSKeyS
----
======
<1> A hypothetical source for tenant information
<2> A cache for `JWSKeySelector`s, keyed by tenant identifier
<2> A cache for ``JWSKeySelector``s, keyed by tenant identifier
<3> Looking up the tenant is more secure than simply calculating the JWK Set endpoint on the fly - the lookup acts as a list of allowed tenants
<4> Create a `JWSKeySelector` via the types of keys that come back from the JWK Set endpoint - the lazy lookup here means that you don't need to configure all tenants at startup

8
docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc
View File

@ -639,7 +639,7 @@ class MyCustomSecurityConfiguration {
----
======
In this way, the set of `RelyingPartyRegistration`s will refresh based on {spring-framework-reference-url}integration/cache/store-configuration.html[the cache's eviction schedule].
In this way, the set of ``RelyingPartyRegistration``s will refresh based on {spring-framework-reference-url}integration/cache/store-configuration.html[the cache's eviction schedule].
[[servlet-saml2login-relyingpartyregistration]]
== RelyingPartyRegistration
@ -971,9 +971,9 @@ As seen so far, Spring Security resolves the `RelyingPartyRegistration` by looki
Depending on the use case, a number of other strategies are also employed to derive one.
For example:
* For processing `<saml2:Response>`s, the `RelyingPartyRegistration` is looked up from the associated `<saml2:AuthRequest>` or from the `<saml2:Response#Issuer>` element
* For processing `<saml2:LogoutRequest>`s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `<saml2:LogoutRequest#Issuer>` element
* For publishing metadata, the `RelyingPartyRegistration`s are looked up from any repository that also implements `Iterable<RelyingPartyRegistration>`
* For processing ``<saml2:Response>``s, the `RelyingPartyRegistration` is looked up from the associated `<saml2:AuthRequest>` or from the `<saml2:Response#Issuer>` element
* For processing ``<saml2:LogoutRequest>``s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `<saml2:LogoutRequest#Issuer>` element
* For publishing metadata, the ``RelyingPartyRegistration``s are looked up from any repository that also implements `Iterable<RelyingPartyRegistration>`
When this needs adjustment, you can turn to the specific components for each of these endpoints targeted at customizing this: