Address Antora Warnings

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

@@ -139,7 +139,7 @@ The following beans should be configured to commence the CAS authentication proc
 ----
 
 For CAS to operate, the `ExceptionTranslationFilter` must have its `authenticationEntryPoint` property set to the `CasAuthenticationEntryPoint` bean.
-This can easily be done using xref:servlet/appendix/namespace.adoc#nsa-http-entry-point-ref[entry-point-ref] as is done in the example above.
+This can easily be done using xref:servlet/appendix/namespace/http.adoc#nsa-http-entry-point-ref[entry-point-ref] as is done in the example above.
 The `CasAuthenticationEntryPoint` must refer to the `ServiceProperties` bean (discussed above), which provides the URL to the enterprise's CAS login server.
 This is where the user's browser will be redirected.
 

docs/modules/ROOT/pages/servlet/integrations/websocket.adoc

@@ -27,7 +27,7 @@ Spring Security 4.0 has introduced authorization support for WebSockets through
 
 In Spring Security 5.8, this support has been refreshed to use the `AuthorizationManager` API.
 
-To configure authorization using Java Configuration, simply include the `@EnableWebSocketSecurity` annotation and publish an `AuthorizationManager<Message<?>>` bean or in XML use the `use-authorization-manager` attribute.
+To configure authorization using Java Configuration, simply include the `@EnableWebSocketSecurity` annotation and publish an `AuthorizationManager<Message<?>>` bean or in xref:servlet/appendix/namespace/websocket.adoc#nsa-websocket-security[XML] use the `use-authorization-manager` attribute.
 One way to do this is by using the `AuthorizationManagerMessageMatcherRegistry` to specify endpoint patterns like so:
 
 ====
@@ -41,7 +41,7 @@ public class WebSocketSecurityConfig {
     @Bean
     AuthorizationManager<Message<?>> messageAuthorizationManager(MessageMatcherDelegatingAuthorizationManager.Builder messages) {
         messages
-                .simpDestMatchers("/user/**").authenticated() // <3>
+                .simpDestMatchers("/user/**").hasRole("USER") // <3>
 
         return messages.build();
     }
@@ -56,36 +56,24 @@ public class WebSocketSecurityConfig {
 open class WebSocketSecurityConfig { // <1> <2>
     @Bean
     fun messageAuthorizationManager(messages: MessageMatcherDelegatingAuthorizationManager.Builder): AuthorizationManager<Message<?>> {
-        messages.simpDestMatchers("/user/**").authenticated() // <3>
+        messages.simpDestMatchers("/user/**").hasRole("USER") // <3>
         return messages.build()
     }
 }
 ----
-<1> Any inbound CONNECT message requires a valid CSRF token to enforce the <<websocket-sameorigin,Same Origin Policy>>.
-<2> The `SecurityContextHolder` is populated with the user within the `simpUser` header attribute for any inbound request.
-<3> Our messages require the proper authorization. Specifically, any inbound message that starts with `/user/` will requires `ROLE_USER`. You can find additional details on authorization in <<websocket-authorization>>
-====
-
-Spring Security also provides xref:servlet/appendix/namespace/websocket.adoc#nsa-websocket-security[XML Namespace] support for securing WebSockets.
-A comparable XML based configuration looks like the following:
 
-====
-[source,xml]
+.Xml
+[source,xml,role="secondary"]
 ----
-<websocket-message-broker use-authorization-manager="true">
-    <intercept-message pattern="/user/**" access="authenticated"/>
+<websocket-message-broker use-authorization-manager="true"> <1> <2>
+    <intercept-message pattern="/user/**" access="hasRole('USER')"/> <3>
 </websocket-message-broker>
 ----
+<1> Any inbound CONNECT message requires a valid CSRF token to enforce the <<websocket-sameorigin,Same Origin Policy>>.
+<2> The `SecurityContextHolder` is populated with the user within the `simpUser` header attribute for any inbound request.
+<3> Our messages require the proper authorization. Specifically, any inbound message that starts with `/user/` will require `ROLE_USER`. You can find additional details on authorization in <<websocket-authorization>>
 ====
 
-This will ensure that:
-
-<1> Any inbound CONNECT message requires a valid CSRF token to enforce <<websocket-sameorigin,Same Origin Policy>>
-<2> The SecurityContextHolder is populated with the user within the simpUser header attribute for any inbound request.
-<3> Our messages require the proper authorization. Specifically, any inbound message that starts with "/user/" will require ROLE_USER. Additional details on authorization can be found in <<websocket-authorization>>
-====
-
-
 === Custom Authorization
 
 When using `AuthorizationManager`, customization is quite simple.

docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc

@@ -668,7 +668,7 @@ The prevailing URI patterns are as follows:
 * `+/saml2/authenticate/{registrationId}+` - The endpoint that xref:servlet/saml2/login/authentication-requests.adoc[generates a `<saml2:AuthnRequest>`] based on the configurations for that `RelyingPartyRegistration` and sends it to the asserting party
 * `+/login/saml2/sso/+` - The endpoint that xref:servlet/saml2/login/authentication.adoc[authenticates an asserting party's `<saml2:Response>`]; the `RelyingPartyRegistration` is looked up from previously authenticated state or the response's issuer if needed; also supports `+/login/saml2/sso/{registrationId}+`
 * `+/logout/saml2/sso+` - The endpoint that xref:servlet/saml2/logout.adoc[processes `<saml2:LogoutRequest>` and `<saml2:LogoutResponse>` payloads]; the `RelyingPartyRegistration` is looked up from previously authenticated state or the request's issuer if needed; also supports `+/logout/saml2/slo/{registrationId}+`
-* `+/saml2/metadata+` - The xref:servlet/saml2/metadata.adoc[relying party metadata] for the set of `RelyingPartyRegistration`s; also supports `+/saml2/metadata/{registrationId}+` or `+/saml2/service-provider-metadata/{registrationId}+` for a specific `RelyingPartyRegistration`
+* `+/saml2/metadata+` - The xref:servlet/saml2/metadata.adoc[relying party metadata] for the set of ``RelyingPartyRegistration``s; also supports `+/saml2/metadata/{registrationId}+` or `+/saml2/service-provider-metadata/{registrationId}+` for a specific `RelyingPartyRegistration`
 
 Since the `registrationId` is the primary identifier for a `RelyingPartyRegistration`, it is needed in the URL for unauthenticated scenarios.
 If you wish to remove the `registrationId` from the URL for any reason, you can <<servlet-saml2login-rpr-relyingpartyregistrationresolver,specify a `RelyingPartyRegistrationResolver`>> to tell Spring Security how to look up the `registrationId`.