Fix the use of "s" with code blocks in docs

docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc

@@ -121,7 +121,7 @@ This property can also be supplied directly on the <<webflux-oauth2resourceserve
 [[webflux-oauth2resourceserver-jwt-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
-There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
+There are two ``@Bean``s that Spring Boot generates on Resource Server's behalf.
 
 The first is a `SecurityWebFilterChain` that configures the app as a resource server. When including `spring-security-oauth2-jose`, this `SecurityWebFilterChain` looks like:
 
@@ -1045,7 +1045,7 @@ fun forFoosEyesOnly(): Mono<String> {
 [[webflux-oauth2resourceserver-opaque-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
-There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
+There are two ``@Bean``s that Spring Boot generates on Resource Server's behalf.
 
 The first is a `SecurityWebFilterChain` that configures the app as a resource server.
 When use Opaque Token, this `SecurityWebFilterChain` looks like:

docs/manual/src/docs/asciidoc/_includes/reactive/webflux.adoc

@@ -130,7 +130,7 @@ You can find more examples of explicit configuration in unit tests, by searching
 [[jc-webflux-multiple-filter-chains]]
 === Multiple Chains Support
 
-You can configure multiple `SecurityWebFilterChain` instances to separate configuration by `RequestMatcher` s.
+You can configure multiple `SecurityWebFilterChain` instances to separate configuration by ``RequestMatcher``s.
 
 For example, you can isolate configuration for URLs that start with `/api`, like so:
 

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc

@@ -26,8 +26,8 @@ Anonymous authentication support is provided automatically when using the HTTP c
 You don't need to configure the beans described here unless you are using traditional bean configuration.
 
 Three classes that together provide the anonymous authentication feature.
-`AnonymousAuthenticationToken` is an implementation of `Authentication`, and stores the `GrantedAuthority` s which apply to the anonymous principal.
-There is a corresponding `AnonymousAuthenticationProvider`, which is chained into the `ProviderManager` so that `AnonymousAuthenticationToken` s are accepted.
+`AnonymousAuthenticationToken` is an implementation of `Authentication`, and stores the ``GrantedAuthority``s which apply to the anonymous principal.
+There is a corresponding `AnonymousAuthenticationProvider`, which is chained into the `ProviderManager` so that ``AnonymousAuthenticationToken``s are accepted.
 Finally, there is an `AnonymousAuthenticationFilter`, which is chained after the normal authentication mechanisms and automatically adds an `AnonymousAuthenticationToken` to the `SecurityContextHolder` if there is no existing `Authentication` held there.
 The definition of the filter and authentication provider appears as follows:
 
@@ -91,7 +91,7 @@ For example:
 === AuthenticationTrustResolver
 Rounding out the anonymous authentication discussion is the `AuthenticationTrustResolver` interface, with its corresponding `AuthenticationTrustResolverImpl` implementation.
 This interface provides an `isAnonymous(Authentication)` method, which allows interested classes to take into account this special type of authentication status.
-The `ExceptionTranslationFilter` uses this interface in processing `AccessDeniedException` s.
+The `ExceptionTranslationFilter` uses this interface in processing ``AccessDeniedException``s.
 If an `AccessDeniedException` is thrown, and the authentication is of an anonymous type, instead of throwing a 403 (forbidden) response, the filter will instead commence the `AuthenticationEntryPoint` so the principal can authenticate properly.
 This is a necessary distinction, otherwise principals would always be deemed "authenticated" and never be given an opportunity to login via form, basic, digest or some other normal authentication mechanism.
 

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/cas.adoc

@@ -23,7 +23,7 @@ Inside the WAR file you will customise the login and other single sign on pages
 When deploying a CAS 3.4 server, you will also need to specify an `AuthenticationHandler` in the `deployerConfigContext.xml` included with CAS.
 The `AuthenticationHandler` has a simple method that returns a boolean as to whether a given set of Credentials is valid.
 Your `AuthenticationHandler` implementation will need to link into some type of backend authentication repository, such as an LDAP server or database.
-CAS itself includes numerous `AuthenticationHandler` s out of the box to assist with this.
+CAS itself includes numerous ``AuthenticationHandler``s out of the box to assist with this.
 When you download and deploy the server war file, it is set up to successfully authenticate users who enter a password matching their username, which is useful for testing.
 
 Apart from the CAS server itself, the other key players are of course the secure web applications deployed throughout your enterprise.
@@ -57,7 +57,7 @@ The processing filter will construct a `UsernamePasswordAuthenticationToken` rep
 The principal will be equal to `CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER`, whilst the credentials will be the service ticket opaque value.
 This authentication request will then be handed to the configured `AuthenticationManager`.
 * The `AuthenticationManager` implementation will be the `ProviderManager`, which is in turn configured with the `CasAuthenticationProvider`.
-The `CasAuthenticationProvider` only responds to `UsernamePasswordAuthenticationToken` s containing the CAS-specific principal (such as `CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER`) and `CasAuthenticationToken` s (discussed later).
+The `CasAuthenticationProvider` only responds to ``UsernamePasswordAuthenticationToken``s containing the CAS-specific principal (such as `CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER`) and ``CasAuthenticationToken``s (discussed later).
 * `CasAuthenticationProvider` will validate the service ticket using a `TicketValidator` implementation.
 This will typically be a `Cas20ServiceTicketValidator` which is one of the classes included in the CAS client library.
 In the event the application needs to validate proxy tickets, the `Cas20ProxyTicketValidator` is used.

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/jaas.adoc

@@ -16,7 +16,7 @@ The `AbstractJaasAuthenticationProvider` has a number of dependencies that can b
 
 [[jaas-callbackhandler]]
 ==== JAAS CallbackHandler
-Most JAAS `LoginModule` s require a callback of some sort.
+Most JAAS ``LoginModule``s require a callback of some sort.
 These callbacks are usually used to obtain the username and password from the user.
 
 In a Spring Security deployment, Spring Security is responsible for this user interaction (via the authentication mechanism).
@@ -26,10 +26,10 @@ Therefore, the JAAS package for Spring Security provides two default callback ha
 Each of these callback handlers implement `JaasAuthenticationCallbackHandler`.
 In most cases these callback handlers can simply be used without understanding the internal mechanics.
 
-For those needing full control over the callback behavior, internally `AbstractJaasAuthenticationProvider` wraps these `JaasAuthenticationCallbackHandler` s with an `InternalCallbackHandler`.
+For those needing full control over the callback behavior, internally `AbstractJaasAuthenticationProvider` wraps these ``JaasAuthenticationCallbackHandler``s with an `InternalCallbackHandler`.
 The `InternalCallbackHandler` is the class that actually implements JAAS normal `CallbackHandler` interface.
-Any time that the JAAS `LoginModule` is used, it is passed a list of application context configured `InternalCallbackHandler` s.
-If the `LoginModule` requests a callback against the `InternalCallbackHandler` s, the callback is in-turn passed to the `JaasAuthenticationCallbackHandler` s being wrapped.
+Any time that the JAAS `LoginModule` is used, it is passed a list of application context configured ``InternalCallbackHandler``s.
+If the `LoginModule` requests a callback against the ``InternalCallbackHandler``s, the callback is in-turn passed to the ``JaasAuthenticationCallbackHandler``s being wrapped.
 
 
 [[jaas-authoritygranter]]
@@ -37,15 +37,15 @@ If the `LoginModule` requests a callback against the `InternalCallbackHandler` s
 JAAS works with principals.
 Even "roles" are represented as principals in JAAS.
 Spring Security, on the other hand, works with `Authentication` objects.
-Each `Authentication` object contains a single principal, and multiple `GrantedAuthority` s.
+Each `Authentication` object contains a single principal, and multiple ``GrantedAuthority``s.
 To facilitate mapping between these different concepts, Spring Security's JAAS package includes an `AuthorityGranter` interface.
 
-An `AuthorityGranter` is responsible for inspecting a JAAS principal and returning a set of `String` s, representing the authorities assigned to the principal.
+An `AuthorityGranter` is responsible for inspecting a JAAS principal and returning a set of ``String``s, representing the authorities assigned to the principal.
 For each returned authority string, the `AbstractJaasAuthenticationProvider` creates a `JaasGrantedAuthority` (which implements Spring Security's `GrantedAuthority` interface) containing the authority string and the JAAS principal that the `AuthorityGranter` was passed.
 The `AbstractJaasAuthenticationProvider` obtains the JAAS principals by firstly successfully authenticating the user's credentials using the JAAS `LoginModule`, and then accessing the `LoginContext` it returns.
 A call to `LoginContext.getSubject().getPrincipals()` is made, with each resulting principal passed to each `AuthorityGranter` defined against the `AbstractJaasAuthenticationProvider.setAuthorityGranters(List)` property.
 
-Spring Security does not include any production `AuthorityGranter` s given that every JAAS principal has an implementation-specific meaning.
+Spring Security does not include any production ``AuthorityGranter``s given that every JAAS principal has an implementation-specific meaning.
 However, there is a `TestAuthorityGranter` in the unit tests that demonstrates a simple `AuthorityGranter` implementation.
 
 
@@ -59,7 +59,7 @@ This means that `DefaultJaasAuthenticationProvider` is not bound any particular
 [[jaas-inmemoryconfiguration]]
 ==== InMemoryConfiguration
 In order to make it easy to inject a `Configuration` into `DefaultJaasAuthenticationProvider`, a default in-memory implementation named `InMemoryConfiguration` is provided.
-The implementation constructor accepts a `Map` where each key represents a login configuration name and the value represents an `Array` of `AppConfigurationEntry` s.
+The implementation constructor accepts a `Map` where each key represents a login configuration name and the value represents an `Array` of ``AppConfigurationEntry``s.
 `InMemoryConfiguration` also supports a default `Array` of `AppConfigurationEntry` objects that will be used if no mapping is found within the provided `Map`.
 For details, refer to the class level javadoc of `InMemoryConfiguration`.
 

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc

@@ -101,7 +101,7 @@ We'll look at these in turn.
 This implementation supports the simpler approach described in <<remember-me-hash-token>>.
 `TokenBasedRememberMeServices` generates a `RememberMeAuthenticationToken`, which is processed by `RememberMeAuthenticationProvider`.
 A `key` is shared between this authentication provider and the `TokenBasedRememberMeServices`.
-In addition, `TokenBasedRememberMeServices` requires A UserDetailsService from which it can retrieve the username and password for signature comparison purposes, and generate the `RememberMeAuthenticationToken` to contain the correct `GrantedAuthority` s.
+In addition, `TokenBasedRememberMeServices` requires A UserDetailsService from which it can retrieve the username and password for signature comparison purposes, and generate the `RememberMeAuthenticationToken` to contain the correct ``GrantedAuthority``s.
 Some sort of logout command should be provided by the application that invalidates the cookie if the user requests this.
 `TokenBasedRememberMeServices` also implements Spring Security's `LogoutHandler` interface so can be used with `LogoutFilter` to have the cookie cleared automatically.
 

docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc

@@ -186,7 +186,7 @@ This is the default in Servlet 3.1 and newer containers.
 
 
 When session fixation protection occurs, it results in a `SessionFixationProtectionEvent` being published in the application context.
-If you use `changeSessionId`, this protection will __also__ result in any  `javax.servlet.http.HttpSessionIdListener` s being notified, so use caution if your code listens for both events.
+If you use `changeSessionId`, this protection will __also__ result in any  ``javax.servlet.http.HttpSessionIdListener``s being notified, so use caution if your code listens for both events.
 See the <<session-mgmt,Session Management>> chapter for additional information.
 
 === SessionManagementFilter

docs/manual/src/docs/asciidoc/_includes/servlet/authorization/acls.adoc

@@ -16,7 +16,7 @@ Using Spring Security as the foundation, you have several approaches that can be
 * Write your business methods to enforce the security.
 You could consult a collection within the `Customer` domain object instance to determine which users have access.
 By using the `SecurityContextHolder.getContext().getAuthentication()`, you'll be able to access the `Authentication` object.
-* Write an `AccessDecisionVoter` to enforce the security from the `GrantedAuthority[]` s stored in the `Authentication` object.
+* Write an `AccessDecisionVoter` to enforce the security from the ``GrantedAuthority[]``s stored in the `Authentication` object.
 This would mean your `AuthenticationManager` would need to populate the `Authentication` with custom ``GrantedAuthority[]``s representing each of the `Customer` domain object instances the principal has access to.
 * Write an `AccessDecisionVoter` to enforce the security and open the target `Customer` domain object directly.
 This would mean your voter needs access to a DAO that allows it to retrieve the `Customer` object.
@@ -26,8 +26,8 @@ It would then access the `Customer` object's collection of approved users and ma
 Each one of these approaches is perfectly legitimate.
 However, the first couples your authorization checking to your business code.
 The main problems with this include the enhanced difficulty of unit testing and the fact it would be more difficult to reuse the `Customer` authorization logic elsewhere.
-Obtaining the `GrantedAuthority[]` s from the `Authentication` object is also fine, but will not scale to large numbers of `Customer` s.
-If a user might be able to access 5,000 `Customer` s (unlikely in this case, but imagine if it were a popular vet for a large Pony Club!) the amount of memory consumed and time required to construct the `Authentication` object would be undesirable.
+Obtaining the ``GrantedAuthority[]``s from the `Authentication` object is also fine, but will not scale to large numbers of ``Customer``s.
+If a user might be able to access 5,000 ``Customer``s (unlikely in this case, but imagine if it were a popular vet for a large Pony Club!) the amount of memory consumed and time required to construct the `Authentication` object would be undesirable.
 The final method, opening the `Customer` directly from external code, is probably the best of the three.
 It achieves separation of concerns, and doesn't misuse memory or CPU cycles, but it is still inefficient in that both the `AccessDecisionVoter` and the eventual business method itself will perform a call to the DAO responsible for retrieving the `Customer` object.
 Two accesses per method invocation is clearly undesirable.
@@ -91,11 +91,11 @@ Now that we've provided a basic overview of what the ACL system does, and what i
 The key interfaces are:
 
 
-* `Acl`: Every domain object has one and only one `Acl` object, which internally holds the `AccessControlEntry` s as well as knows the owner of the `Acl`.
+* `Acl`: Every domain object has one and only one `Acl` object, which internally holds the ``AccessControlEntry``s as well as knows the owner of the `Acl`.
 An Acl does not refer directly to the domain object, but instead to an `ObjectIdentity`.
 The `Acl` is stored in the ACL_OBJECT_IDENTITY table.
 
-* `AccessControlEntry`: An `Acl` holds multiple `AccessControlEntry` s, which are often abbreviated as ACEs in the framework.
+* `AccessControlEntry`: An `Acl` holds multiple ``AccessControlEntry``s, which are often abbreviated as ACEs in the framework.
 Each ACE refers to a specific tuple of `Permission`, `Sid` and `Acl`.
 An ACE can also be granting or non-granting and contain audit settings.
 The ACE is stored in the ACL_ENTRY table.
@@ -103,7 +103,7 @@ The ACE is stored in the ACL_ENTRY table.
 * `Permission`: A permission represents a particular immutable bit mask, and offers convenience functions for bit masking and outputting information.
 The basic permissions presented above (bits 0 through 4) are contained in the `BasePermission` class.
 
-* `Sid`: The ACL module needs to refer to principals and `GrantedAuthority[]` s.
+* `Sid`: The ACL module needs to refer to principals and ``GrantedAuthority[]``s.
 A level of indirection is provided by the `Sid` interface, which is an abbreviation of "security identity".
 Common classes include `PrincipalSid` (to represent the principal inside an `Authentication` object) and `GrantedAuthoritySid`.
 The security identity information is stored in the ACL_SID table.

docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc

@@ -8,7 +8,7 @@
 == Authorities
 <<servlet-authentication-authentication,`Authentication`>>, discusses how all `Authentication` implementations store a list of `GrantedAuthority` objects.
 These represent the authorities that have been granted to the principal.
-The `GrantedAuthority` objects are inserted into the `Authentication` object by the `AuthenticationManager` and are later read by `AccessDecisionManager` s when making authorization decisions.
+The `GrantedAuthority` objects are inserted into the `Authentication` object by the `AuthenticationManager` and are later read by ``AccessDecisionManager``s when making authorization decisions.
 
 `GrantedAuthority` is an interface with only one method:
 
@@ -20,8 +20,8 @@ String getAuthority();
 ----
 
 This method allows
-`AccessDecisionManager` s to obtain a precise `String` representation of the `GrantedAuthority`.
-By returning a representation as a `String`, a `GrantedAuthority` can be easily "read" by most `AccessDecisionManager` s.
+``AccessDecisionManager``s to obtain a precise `String` representation of the `GrantedAuthority`.
+By returning a representation as a `String`, a `GrantedAuthority` can be easily "read" by most ``AccessDecisionManager``s.
 If a `GrantedAuthority` cannot be precisely represented as a `String`, the `GrantedAuthority` is considered "complex" and `getAuthority()` must return `null`.
 
 An example of a "complex" `GrantedAuthority` would be an implementation that stores a list of operations and authority thresholds that apply to different customer account numbers.
@@ -30,7 +30,7 @@ This will indicate to any `AccessDecisionManager` that it will need to specifica
 
 Spring Security includes one concrete `GrantedAuthority` implementation, `SimpleGrantedAuthority`.
 This allows any user-specified `String` to be converted into a `GrantedAuthority`.
-All `AuthenticationProvider` s included with the security architecture use `SimpleGrantedAuthority` to populate the `Authentication` object.
+All ``AuthenticationProvider``s included with the security architecture use `SimpleGrantedAuthority` to populate the `Authentication` object.
 
 
 [[authz-pre-invocation]]
@@ -92,7 +92,7 @@ Concrete implementations return an `int`, with possible values               bei
 A voting implementation will return `ACCESS_ABSTAIN` if it has no opinion on an authorization decision.
 If it does have an opinion, it must return either `ACCESS_DENIED` or `ACCESS_GRANTED`.
 
-There are three concrete `AccessDecisionManager` s provided with Spring Security that tally the votes.
+There are three concrete ``AccessDecisionManager``s provided with Spring Security that tally the votes.
 The `ConsensusBased` implementation will grant or deny access based on the consensus of non-abstain votes.
 Properties are provided to control behavior in the event of an equality of votes or if all votes are abstain.
 The `AffirmativeBased` implementation will grant access if one or more `ACCESS_GRANTED` votes were received (i.e. a deny vote will be ignored, provided there was at least one grant vote).
@@ -142,7 +142,7 @@ Whilst you could easily implement your own AOP concern to achieve this, Spring S
 .After Invocation Implementation
 image::images/after-invocation.png[]
 
-Like many other parts of Spring Security, `AfterInvocationManager` has a single concrete implementation, `AfterInvocationProviderManager`, which polls a list of `AfterInvocationProvider` s.
+Like many other parts of Spring Security, `AfterInvocationManager` has a single concrete implementation, `AfterInvocationProviderManager`, which polls a list of ``AfterInvocationProvider``s.
 Each `AfterInvocationProvider` is allowed to modify the return object or throw an `AccessDeniedException`.
 Indeed multiple providers can modify the object, as the result of the previous provider is passed to the next in the list.
 

docs/manual/src/docs/asciidoc/_includes/servlet/authorization/secure-objects.adoc

@@ -4,12 +4,12 @@
 
 [[aop-alliance]]
 === AOP Alliance (MethodInvocation) Security Interceptor
-Prior to Spring Security 2.0, securing `MethodInvocation` s needed quite a lot of boiler plate configuration.
+Prior to Spring Security 2.0, securing ``MethodInvocation``s needed quite a lot of boiler plate configuration.
 Now the recommended approach for method security is to use <<ns-method-security,namespace configuration>>.
 This way the method security infrastructure beans are configured automatically for you so you don't really need to know about the implementation classes.
 We'll just provide a quick overview of the classes that are involved here.
 
-Method security is enforced using a `MethodSecurityInterceptor`, which secures `MethodInvocation` s.
+Method security is enforced using a `MethodSecurityInterceptor`, which secures ``MethodInvocation``s.
 Depending on the configuration approach, an interceptor may be specific to a single bean or shared between multiple beans.
 The interceptor uses a `MethodSecurityMetadataSource` instance to obtain the configuration attributes that apply to a particular method invocation.
 `MapBasedMethodSecurityMetadataSource` is used to store configuration attributes keyed by method names (which can be wildcarded) and will be used internally when the attributes are defined in the application context using the `<intercept-methods>` or `<protect-point>` elements.
@@ -66,7 +66,7 @@ Let's first consider how the `AspectJSecurityInterceptor` is configured in the S
 
 
 As you can see, aside from the class name, the `AspectJSecurityInterceptor` is exactly the same as the AOP Alliance security interceptor.
-Indeed the two interceptors can share the same `securityMetadataSource`, as the `SecurityMetadataSource` works with `java.lang.reflect.Method` s rather than an AOP library-specific class.
+Indeed the two interceptors can share the same `securityMetadataSource`, as the `SecurityMetadataSource` works with ``java.lang.reflect.Method``s rather than an AOP library-specific class.
 Of course, your access decisions have access to the relevant AOP library-specific invocation (ie `MethodInvocation` or `JoinPoint`) and as such can consider a range of addition criteria when making access decisions (such as method arguments).
 
 Next you'll need to define an AspectJ `aspect`.

docs/manual/src/docs/asciidoc/_includes/servlet/exploits/firewall.adoc

@@ -145,7 +145,7 @@ This requirement can be relaxed or adjusted as necessary using the following met
 
 NOTE: Also, parameter values can be controlled with `setAllowedParameterValues(Predicate)`.
 
-For example, to switch off this check, you can wire your `StrictHttpFirewall` with `Predicate` s that always return `true`, like so:
+For example, to switch off this check, you can wire your `StrictHttpFirewall` with ``Predicate``s that always return `true`, like so:
 
 .Allow Any Header Name, Header Value, and Parameter Name
 ====

docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-resourceserver.adoc

@@ -192,7 +192,7 @@ This property can also be supplied directly on the <<oauth2resourceserver-jwt-jw
 [[oauth2resourceserver-jwt-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
-There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
+There are two ``@Bean``s that Spring Boot generates on Resource Server's behalf.
 
 The first is a `WebSecurityConfigurerAdapter` that configures the app as a resource server. When including `spring-security-oauth2-jose`, this `WebSecurityConfigurerAdapter` looks like:
 
@@ -1609,7 +1609,7 @@ fun forFoosEyesOnly(): String {
 [[oauth2resourceserver-opaque-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
-There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
+There are two ``@Bean``s that Spring Boot generates on Resource Server's behalf.
 
 The first is a `WebSecurityConfigurerAdapter` that configures the app as a resource server.
 When use Opaque Token, this `WebSecurityConfigurerAdapter` looks like:

docs/manual/src/docs/asciidoc/_includes/servlet/saml2/saml2-login.adoc

@@ -107,7 +107,7 @@ where
 
 * `https://idp.example.com/issuer` is the value contained in the `Issuer` attribute of the SAML responses that the identity provider will issue
 * `classpath:idp.crt` is the location on the classpath for the identity provider's certificate for verifying SAML responses, and
-* `https://idp.example.com/issuer/sso` is the endpoint where the identity provider is expecting `AuthnRequest` s.
+* `https://idp.example.com/issuer/sso` is the endpoint where the identity provider is expecting ``AuthnRequest``s.
 * `adfs` is <<servlet-saml2login-relyingpartyregistrationid, an arbitrary identifier you choose>>
 
 And that's it!
@@ -152,7 +152,7 @@ To achieve this, any interfaces or classes where Spring Security uses OpenSAML i
 This makes it possible for you to switch out OpenSAML for some other library or even an unsupported version of OpenSAML.
 
 As a natural outcome of the above two goals, Spring Security's SAML API is quite small relative to other modules.
-Instead, classes like `OpenSaml4AuthenticationRequestFactory` and `OpenSaml4AuthenticationProvider` expose `Converter` s that customize various steps in the authentication process.
+Instead, classes like `OpenSaml4AuthenticationRequestFactory` and `OpenSaml4AuthenticationProvider` expose ``Converter``s that customize various steps in the authentication process.
 
 For example, once your application receives a `SAMLResponse` and delegates to `Saml2WebSsoAuthenticationFilter`, the filter will delegate to `OpenSaml4AuthenticationProvider`.
 
@@ -295,7 +295,7 @@ The `requireInitialize` method may only be called once per application instance.
 [[servlet-saml2login-sansboot]]
 === Overriding or Replacing Boot Auto Configuration
 
-There are two `@Bean` s that Spring Boot generates for a relying party.
+There are two ``@Bean``s that Spring Boot generates for a relying party.
 
 The first is a `WebSecurityConfigurerAdapter` that configures the app as a relying party.
 When including `spring-security-saml2-service-provider`, the `WebSecurityConfigurerAdapter` looks like:
@@ -763,7 +763,7 @@ class SingleRelyingPartyRegistrationResolver(delegate: RelyingPartyRegistrationR
 ----
 ====
 
-Then, you can provide this resolver to the appropriate filters that <<servlet-saml2login-sp-initiated-factory, produce `<saml2:AuthnRequest>` s>>, <<servlet-saml2login-authenticate-responses, authenticate `<saml2:Response>` s>>, and <<servlet-saml2login-metadata, produce `<saml2:SPSSODescriptor>` metadata>>.
+Then, you can provide this resolver to the appropriate filters that <<servlet-saml2login-sp-initiated-factory, produce ``<saml2:AuthnRequest>``s>>, <<servlet-saml2login-authenticate-responses, authenticate ``<saml2:Response>``s>>, and <<servlet-saml2login-metadata, produce `<saml2:SPSSODescriptor>` metadata>>.
 
 [NOTE]
 Remember that if you have any placeholders in your `RelyingPartyRegistration`, your resolver implementation should resolve them.
@@ -864,7 +864,7 @@ open fun relyingPartyRegistrations(): RelyingPartyRegistrationRepository? {
 ====
 
 [[servlet-saml2login-sp-initiated-factory]]
-=== Producing `<saml2:AuthnRequest>` s
+=== Producing ``<saml2:AuthnRequest>``s
 
 As stated earlier, Spring Security's SAML 2.0 support produces a `<saml2:AuthnRequest>` to commence authentication with the asserting party.
 
@@ -1103,7 +1103,7 @@ class AuthnRequestConverter : Converter<MySaml2AuthenticationRequestContext, Aut
 ----
 ====
 
-Then, you can construct your own `Saml2AuthenticationRequestContextResolver` and `Saml2AuthenticationRequestFactory` and publish them as `@Bean` s:
+Then, you can construct your own `Saml2AuthenticationRequestContextResolver` and `Saml2AuthenticationRequestFactory` and publish them as ``@Bean``s:
 
 ====
 .Java
@@ -1157,7 +1157,7 @@ open fun authenticationRequestFactory(
 ====
 
 [[servlet-saml2login-authenticate-responses]]
-=== Authenticating `<saml2:Response>` s
+=== Authenticating ``<saml2:Response>``s
 
 To verify SAML 2.0 Responses, Spring Security uses <<servlet-saml2login-architecture,`OpenSaml4AuthenticationProvider`>> by default.
 
@@ -1311,7 +1311,7 @@ open class SecurityConfig : WebSecurityConfigurerAdapter() {
 
 [NOTE]
 It's not required to call `OpenSaml4AuthenticationProvider` 's default authentication converter.
-It returns a `Saml2AuthenticatedPrincipal` containing the attributes it extracted from `AttributeStatement` s as well as the single `ROLE_USER` authority.
+It returns a `Saml2AuthenticatedPrincipal` containing the attributes it extracted from ``AttributeStatement``s as well as the single `ROLE_USER` authority.
 
 [[servlet-saml2login-opensamlauthenticationprovider-additionalvalidation]]
 ==== Performing Additional Response Validation
@@ -1341,7 +1341,7 @@ provider.setResponseValidator((responseToken) -> {
 After verifying the signature, it will:
 
 1. Validate `<AudienceRestriction>` and `<DelegationRestriction>` conditions
-2. Validate `<SubjectConfirmation>` s, expect for any IP address information
+2. Validate ``<SubjectConfirmation>``s, expect for any IP address information
 
 To perform additional validation, you can configure your own assertion validator that delegates to `OpenSaml4AuthenticationProvider` 's default and then performs its own.