From eea3b7734f0a849c0d0342ca6beed4563f6cc7e1 Mon Sep 17 00:00:00 2001 From: Josh Cummings Date: Wed, 10 May 2023 15:57:25 -0600 Subject: [PATCH] Address Antora Warnings --- .../pages/servlet/authentication/cas.adoc | 2 +- .../pages/servlet/integrations/websocket.adoc | 32 ++++++------------- .../pages/servlet/saml2/login/overview.adoc | 2 +- 3 files changed, 12 insertions(+), 24 deletions(-) diff --git a/docs/modules/ROOT/pages/servlet/authentication/cas.adoc b/docs/modules/ROOT/pages/servlet/authentication/cas.adoc index 56920bf42d6..264b14ecd8e 100644 --- a/docs/modules/ROOT/pages/servlet/authentication/cas.adoc +++ b/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. diff --git a/docs/modules/ROOT/pages/servlet/integrations/websocket.adoc b/docs/modules/ROOT/pages/servlet/integrations/websocket.adoc index 87a6935f039..380c0397e1e 100644 --- a/docs/modules/ROOT/pages/servlet/integrations/websocket.adoc +++ b/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>` 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>` 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> 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> { - 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 <>. -<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 <> -==== - -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"] ---- - - + <1> <2> + <3> ---- +<1> Any inbound CONNECT message requires a valid CSRF token to enforce the <>. +<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 <> ==== -This will ensure that: - -<1> Any inbound CONNECT message requires a valid CSRF token to enforce <> -<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 <> -==== - - === Custom Authorization When using `AuthorizationManager`, customization is quite simple. diff --git a/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc b/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc index b7a83a0daa1..85a706e1a59 100644 --- a/docs/modules/ROOT/pages/servlet/saml2/login/overview.adoc +++ b/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 ``] 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 ``]; 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 `` and `` 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 <> to tell Spring Security how to look up the `registrationId`.