diff --git a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/multitenancy.adoc b/docs/modules/ROOT/pages/servlet/oauth2/resource-server/multitenancy.adoc index 3982f855cc5..8b1aec78e22 100644 --- a/docs/modules/ROOT/pages/servlet/oauth2/resource-server/multitenancy.adoc +++ b/docs/modules/ROOT/pages/servlet/oauth2/resource-server/multitenancy.adoc @@ -320,7 +320,7 @@ class TenantJWSKeySelector(tenants: TenantRepository) : JWTClaimsSetAwareJWSKeyS ---- ====== <1> A hypothetical source for tenant information -<2> A cache for `JWKKeySelector`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 diff --git a/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc b/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc index 0a929de7d1d..6b42ee631fd 100644 --- a/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc +++ b/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc @@ -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 ``s, the `RelyingPartyRegistration` is looked up from the associated `` or from the `` element -* For processing ``s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `` element -* For publishing metadata, the `RelyingPartyRegistration`s are looked up from any repository that also implements `Iterable` +* For processing ````s, the `RelyingPartyRegistration` is looked up from the associated `` or from the `` element +* For processing ````s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `` element +* For publishing metadata, the ``RelyingPartyRegistration``s are looked up from any repository that also implements `Iterable` When this needs adjustment, you can turn to the specific components for each of these endpoints targeted at customizing this: