From 17d3cc93a8a85b0868d2fb60fb41d88248cd1f98 Mon Sep 17 00:00:00 2001 From: Dmitriy Bogdanov Date: Wed, 15 Sep 2021 13:30:06 +0400 Subject: [PATCH 1/3] Fix some typos and mistakes in docs --- .../_includes/about/authentication/password-storage.adoc | 2 +- .../src/docs/asciidoc/_includes/about/exploits/csrf.adoc | 2 +- .../docs/asciidoc/_includes/about/exploits/headers.adoc | 2 +- .../src/docs/asciidoc/_includes/about/exploits/http.adoc | 2 +- .../servlet/architecture/delegating-filter-proxy.adoc | 2 +- .../architecture/exception-translation-filter.adoc | 2 +- .../_includes/servlet/authentication/anonymous.adoc | 2 +- .../architecture/security-context-holder.adoc | 2 +- .../asciidoc/_includes/servlet/authentication/logout.adoc | 8 ++++---- .../_includes/servlet/authentication/rememberme.adoc | 2 +- .../asciidoc/_includes/servlet/authentication/runas.adoc | 2 +- .../servlet/authentication/session-management.adoc | 2 +- .../_includes/servlet/authentication/unpwd/basic.adoc | 2 +- .../_includes/servlet/authentication/unpwd/form.adoc | 8 ++++---- .../_includes/servlet/authentication/unpwd/in-memory.adoc | 2 +- .../_includes/servlet/authorization/architecture.adoc | 2 +- .../_includes/servlet/authorization/expression-based.adoc | 4 ++-- .../_includes/servlet/java-configuration/index.adoc | 2 +- .../asciidoc/_includes/servlet/saml2/saml2-login.adoc | 1 + 19 files changed, 26 insertions(+), 25 deletions(-) diff --git a/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc b/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc index 89c62dee7dc..94eda552824 100644 --- a/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc @@ -295,7 +295,7 @@ java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the i at org.springframework.security.crypto.password.DelegatingPasswordEncoder.matches(DelegatingPasswordEncoder.java:196) ---- -The easiest way to resolve the error is to switch to explicitly provide the `PasswordEncoder` that you passwords are encoded with. +The easiest way to resolve the error is to switch to explicitly providing the `PasswordEncoder` that your passwords are encoded with. The easiest way to resolve it is to figure out how your passwords are currently being stored and explicitly provide the correct `PasswordEncoder`. If you are migrating from Spring Security 4.2.x you can revert to the previous behavior by <>. diff --git a/docs/manual/src/docs/asciidoc/_includes/about/exploits/csrf.adoc b/docs/manual/src/docs/asciidoc/_includes/about/exploits/csrf.adoc index 27ba109df9b..026faecde62 100644 --- a/docs/manual/src/docs/asciidoc/_includes/about/exploits/csrf.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/about/exploits/csrf.adoc @@ -377,7 +377,7 @@ More information about using multipart forms with Spring can be found within the The first option is to include the actual CSRF token in the body of the request. By placing the CSRF token in the body, the body will be read before authorization is performed. This means that anyone can place temporary files on your server. -However, only authorized users will be able to submit a File that is processed by your application. +However, only authorized users will be able to submit a file that is processed by your application. In general, this is the recommended approach because the temporary file upload should have a negligible impact on most servers. [[csrf-considerations-multipart-url]] diff --git a/docs/manual/src/docs/asciidoc/_includes/about/exploits/headers.adoc b/docs/manual/src/docs/asciidoc/_includes/about/exploits/headers.adoc index ba2abd824b9..565272a29c2 100644 --- a/docs/manual/src/docs/asciidoc/_includes/about/exploits/headers.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/about/exploits/headers.adoc @@ -384,7 +384,7 @@ This is a nice clean-up action to perform on logout. [NOTE] ==== -Refer to the relevant sections to see how to configure both <> based applications. +Refer to the relevant section to see how to configure <> based applications. ==== Spring Security has mechanisms to make it convenient to add the more common security headers to your application. diff --git a/docs/manual/src/docs/asciidoc/_includes/about/exploits/http.adoc b/docs/manual/src/docs/asciidoc/_includes/about/exploits/http.adoc index 5e5e52d1763..44a4e59692e 100644 --- a/docs/manual/src/docs/asciidoc/_includes/about/exploits/http.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/about/exploits/http.adoc @@ -20,7 +20,7 @@ Spring Security provides support for <> == Proxy Server Configuration When using a proxy server it is important to ensure that you have configured your application properly. -For example, many applications will have a load balancer that responds to request for https://example.com/ by forwarding the request to an application server at https://192.168.1:8080 +For example, many applications will have a load balancer that responds to request for https://example.com/ by forwarding the request to an application server at https://192.168.1:8080. Without proper configuration, the application server will not know that the load balancer exists and treat the request as though https://192.168.1:8080 was requested by the client. To fix this you can use https://tools.ietf.org/html/rfc7239[RFC 7239] to specify that a load balancer is being used. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/delegating-filter-proxy.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/delegating-filter-proxy.adoc index a05c740bc20..1ccac8c5843 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/delegating-filter-proxy.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/delegating-filter-proxy.adoc @@ -41,6 +41,6 @@ fun doFilter(request: ServletRequest, response: ServletResponse, chain: FilterCh ---- ==== -Another benefit of `DelegatingFilterProxy` is that it allows delaying looking `Filter` bean instances. +Another benefit of `DelegatingFilterProxy` is that it allows delaying looking `Filter` bean instances up. This is important because the container needs to register the `Filter` instances before the container can startup. However, Spring typically uses a `ContextLoaderListener` to load the Spring Beans which will not be done until after the `Filter` instances need to be registered. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/exception-translation-filter.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/exception-translation-filter.adoc index 67cad58ddf1..941c1fb122f 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/exception-translation-filter.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/exception-translation-filter.adoc @@ -13,7 +13,7 @@ image::{figures}/exceptiontranslationfilter.png[] * image:{icondir}/number_1.png[] First, the `ExceptionTranslationFilter` invokes `FilterChain.doFilter(request, response)` to invoke the rest of the application. * image:{icondir}/number_2.png[] If the user is not authenticated or it is an `AuthenticationException`, then __Start Authentication__. -** The <> is cleared out +** The <> is cleared out. ** The `HttpServletRequest` is saved in the {security-api-url}org/springframework/security/web/savedrequest/RequestCache.html[`RequestCache`]. When the user successfully authenticates, the `RequestCache` is used to replay the original request. // FIXME: add link to authentication success diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc index 8cb386a1537..ec2b8aa2599 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc @@ -14,7 +14,7 @@ You could also omit these pages from the filter chain entirely, thus bypassing t This is what we mean by anonymous authentication. Note that there is no real conceptual difference between a user who is "anonymously authenticated" and an unauthenticated user. Spring Security's anonymous authentication just gives you a more convenient way to configure your access-control attributes. -Calls to servlet API calls such as `getCallerPrincipal`, for example, will still return null even though there is actually an anonymous authentication object in the `SecurityContextHolder`. +Calls to servlet API such as `getCallerPrincipal`, for example, will still return null even though there is actually an anonymous authentication object in the `SecurityContextHolder`. There are other situations where anonymous authentication is useful, such as when an auditing interceptor queries the `SecurityContextHolder` to identify which principal was responsible for a given operation. Classes can be authored more robustly if they know the `SecurityContextHolder` always contains an `Authentication` object, and never `null`. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/security-context-holder.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/security-context-holder.adoc index fa973793a43..60198d48f66 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/security-context-holder.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/security-context-holder.adoc @@ -86,4 +86,4 @@ Other applications might want to have threads spawned by the secure thread also This is achieved by using `SecurityContextHolder.MODE_INHERITABLETHREADLOCAL`. You can change the mode from the default `SecurityContextHolder.MODE_THREADLOCAL` in two ways. The first is to set a system property, the second is to call a static method on `SecurityContextHolder`. -Most applications won't need to change from the default, but if you do, take a look at the JavaDoc for `SecurityContextHolder` to learn more. +Most applications won't need to change from the default, but if you do, take a look at the Javadoc for `SecurityContextHolder` to learn more. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/logout.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/logout.adoc index c824ffe0adb..7ebb287ac2d 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/logout.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/logout.adoc @@ -55,17 +55,17 @@ override fun configure(http: HttpSecurity) { This is automatically applied when using `WebSecurityConfigurerAdapter`. <2> The URL that triggers log out to occur (default is `/logout`). If CSRF protection is enabled (default), then the request must also be a POST. -For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#logoutUrl-java.lang.String-[JavaDoc]. +For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#logoutUrl-java.lang.String-[Javadoc]. <3> The URL to redirect to after logout has occurred. The default is `/login?logout`. -For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#logoutSuccessUrl-java.lang.String-[JavaDoc]. +For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#logoutSuccessUrl-java.lang.String-[Javadoc]. <4> Let's you specify a custom `LogoutSuccessHandler`. If this is specified, `logoutSuccessUrl()` is ignored. -For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#logoutSuccessHandler-org.springframework.security.web.authentication.logout.LogoutSuccessHandler-[JavaDoc]. +For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#logoutSuccessHandler-org.springframework.security.web.authentication.logout.LogoutSuccessHandler-[Javadoc]. <5> Specify whether to invalidate the `HttpSession` at the time of logout. This is *true* by default. Configures the `SecurityContextLogoutHandler` under the covers. -For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#invalidateHttpSession-boolean-[JavaDoc]. +For more information, please consult the {security-api-url}org/springframework/security/config/annotation/web/configurers/LogoutConfigurer.html#invalidateHttpSession-boolean-[Javadoc]. <6> Adds a `LogoutHandler`. `SecurityContextLogoutHandler` is added as the last `LogoutHandler` by default. <7> Allows specifying the names of cookies to be removed on logout success. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc index bcb14227651..e26ca53fa38 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc @@ -34,7 +34,7 @@ Notably, this has a potential security issue in that a captured remember-me toke This is the same issue as with digest authentication. If a principal is aware a token has been captured, they can easily change their password and immediately invalidate all remember-me tokens on issue. If more significant security is needed you should use the approach described in the next section. -Alternatively remember-me services should simply not be used at all. +Alternatively, remember-me services should simply not be used at all. If you are familiar with the topics discussed in the chapter on <>, you can enable remember-me authentication just by adding the `` element: diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/runas.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/runas.adoc index 8eb5de89ec5..0b439ad369a 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/runas.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/runas.adoc @@ -9,7 +9,7 @@ The `RunAsManager` will indicate the replacement `Authentication` object, if any By temporarily replacing the `Authentication` object during the secure object callback phase, the secured invocation will be able to call other objects which require different authentication and authorization credentials. It will also be able to perform any internal security checks for specific `GrantedAuthority` objects. -Because Spring Security provides a number of helper classes that automatically configure remoting protocols based on the contents of the `SecurityContextHolder`, these run-as replacements are particularly useful when calling remote web services +Because Spring Security provides a number of helper classes that automatically configure remoting protocols based on the contents of the `SecurityContextHolder`, these run-as replacements are particularly useful when calling remote web services. [[runas-config]] === Configuration diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc index 0579d4efae4..9cf5c5f6b7e 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc @@ -200,7 +200,7 @@ It will then invoke the configured `SessionAuthenticationStrategy`. If the user is not currently authenticated, the filter will check whether an invalid session ID has been requested (because of a timeout, for example) and will invoke the configured `InvalidSessionStrategy`, if one is set. The most common behaviour is just to redirect to a fixed URL and this is encapsulated in the standard implementation `SimpleRedirectInvalidSessionStrategy`. -The latter is also used when configuring an invalid session URL through the namespace,<>. +The latter is also used when configuring an invalid session URL through the namespace, <>. === SessionAuthenticationStrategy diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/basic.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/basic.adoc index aa2ff02f297..411fefcb137 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/basic.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/basic.adoc @@ -33,7 +33,7 @@ The figure builds off our <> image:{icondir}/number_1.png[] When the user submits their username and password, the `BasicAuthenticationFilter` creates a `UsernamePasswordAuthenticationToken` which is a type of <> by extracting the username and password from the `HttpServletRequest`. image:{icondir}/number_2.png[] Next, the `UsernamePasswordAuthenticationToken` is passed into the `AuthenticationManager` to be authenticated. -The details of what `AuthenticationManager` look like depend on how the <>. +The details of what `AuthenticationManager` looks like depend on how the <>. image:{icondir}/number_3.png[] If authentication fails, then __Failure__ diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/form.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/form.adoc index 27343234e50..f8745f89aba 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/form.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/form.adoc @@ -37,7 +37,7 @@ The figure builds off our <> image:{icondir}/number_1.png[] When the user submits their username and password, the `UsernamePasswordAuthenticationFilter` creates a `UsernamePasswordAuthenticationToken` which is a type of <> by extracting the username and password from the `HttpServletRequest`. image:{icondir}/number_2.png[] Next, the `UsernamePasswordAuthenticationToken` is passed into the `AuthenticationManager` to be authenticated. -The details of what `AuthenticationManager` look like depend on how the <>. +The details of what `AuthenticationManager` looks like depend on how the <>. image:{icondir}/number_3.png[] If authentication fails, then __Failure__ @@ -147,7 +147,7 @@ fun configure(http: HttpSecurity) { [[servlet-authentication-form-custom-html]] When the login page is specified in the Spring Security configuration, you are responsible for rendering the page. // FIXME: default login page rendered by Spring Security -Below is a https://www.thymeleaf.org/[Thymeleaf] template that produces an HTML login form that complies with a login page of `/login`.: +Below is a https://www.thymeleaf.org/[Thymeleaf] template that produces an HTML login form that complies with a login page of `/login`: .Log In Form ==== @@ -189,11 +189,11 @@ There are a few key points about the default HTML form: * If the HTTP parameter logout is found, it indicates the user has logged out successfully Many users will not need much more than to customize the log in page. -However, if needed everything above can be customized with additional configuration. +However, if needed, everything above can be customized with additional configuration. [[servlet-authentication-form-custom-controller]] If you are using Spring MVC, you will need a controller that maps `GET /login` to the login template we created. -A minimal sample `LoginController` can be see below: +A minimal sample `LoginController` can be seen below: .LoginController ==== diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/in-memory.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/in-memory.adoc index a364cee0e1a..d5b178516b9 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/in-memory.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/unpwd/in-memory.adoc @@ -1,7 +1,7 @@ [[servlet-authentication-inmemory]] = In-Memory Authentication -Spring Security's `InMemoryUserDetailsManager` implements <> to provide support for username/password based authentication that is retrieved in memory. +Spring Security's `InMemoryUserDetailsManager` implements <> to provide support for username/password based authentication that is stored in memory. `InMemoryUserDetailsManager` provides management of `UserDetails` by implementing the `UserDetailsManager` interface. `UserDetails` based authentication is used by Spring Security when it is configured to <> for authentication. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc index 15de8dbf70d..240727384a7 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc @@ -8,7 +8,7 @@ == Authorities <>, 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: diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/expression-based.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/expression-based.adoc index 0fc34842d8e..1070783c92c 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/expression-based.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/expression-based.adoc @@ -1,7 +1,7 @@ [[el-access]] == Expression-Based Access Control -Spring Security 3.0 introduced the ability to use Spring EL expressions as an authorization mechanism in addition to the simple use of configuration attributes and access-decision voters which have seen before. +Spring Security 3.0 introduced the ability to use Spring EL expressions as an authorization mechanism in addition to the simple use of configuration attributes and access-decision voters which have been seen before. Expression-based access control is built on the same architecture but allows complicated Boolean logic to be encapsulated in a single expression. @@ -296,7 +296,7 @@ fun deletePermission(contact: Contact?, recipient: Sid?, permission: Permission? ---- ==== -Here we're actually using a method argument as part of the expression to decide whether the current user has the "admin"permission for the given contact. +Here we're actually using a method argument as part of the expression to decide whether the current user has the "admin" permission for the given contact. The built-in `hasPermission()` expression is linked into the Spring Security ACL module through the application context, as we'll <>. You can access any of the method arguments by name as expression variables. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/java-configuration/index.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/java-configuration/index.adoc index 3ba5432ddcf..48205a64a64 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/java-configuration/index.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/java-configuration/index.adoc @@ -312,7 +312,7 @@ public class Config extends WebSecurityConfigurerAdapter { Spring Security's Java Configuration does not expose every property of every object that it configures. This simplifies the configuration for a majority of users. -Afterall, if every property was exposed, users could use standard bean configuration. +After all, if every property was exposed, users could use standard bean configuration. While there are good reasons to not directly expose every property, users may still need more advanced configuration options. To address this Spring Security introduces the concept of an `ObjectPostProcessor` which can be used to modify or replace many of the Object instances created by the Java Configuration. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/saml2/saml2-login.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/saml2/saml2-login.adoc index b4483fa5bb1..29af4dee8c0 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/saml2/saml2-login.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/saml2/saml2-login.adoc @@ -1694,6 +1694,7 @@ Also, your application can participate in an AP-initiated logout when the assert === Configuring Logout Endpoints There are three behaviors that can be triggered by different endpoints: + * RP-initiated logout, which allows an authenticated user to `POST` and trigger the logout process by sending the asserting party a `` * AP-initiated logout, which allows an asserting party to send a `` to the application * AP logout response, which allows an asserting party to send a `` in response to the RP-initiated `` From ccfa54ec9a69ac04d8e5c1fddd20a8d0a5bb3dc5 Mon Sep 17 00:00:00 2001 From: Dmitriy Bogdanov Date: Wed, 15 Sep 2021 13:34:38 +0400 Subject: [PATCH 2/3] Fix the use of "s" with code blocks in docs --- .../reactive/oauth2/resource-server.adoc | 4 ++-- .../asciidoc/_includes/reactive/webflux.adoc | 2 +- .../servlet/authentication/anonymous.adoc | 6 +++--- .../_includes/servlet/authentication/cas.adoc | 4 ++-- .../_includes/servlet/authentication/jaas.adoc | 16 ++++++++-------- .../servlet/authentication/rememberme.adoc | 2 +- .../authentication/session-management.adoc | 2 +- .../_includes/servlet/authorization/acls.adoc | 12 ++++++------ .../servlet/authorization/architecture.adoc | 12 ++++++------ .../servlet/authorization/secure-objects.adoc | 6 +++--- .../_includes/servlet/exploits/firewall.adoc | 2 +- .../servlet/oauth2/oauth2-resourceserver.adoc | 4 ++-- .../_includes/servlet/saml2/saml2-login.adoc | 18 +++++++++--------- 13 files changed, 45 insertions(+), 45 deletions(-) diff --git a/docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc b/docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc index bcd79327a1d..8f45337314f 100644 --- a/docs/manual/src/docs/asciidoc/_includes/reactive/oauth2/resource-server.adoc +++ b/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-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: diff --git a/docs/manual/src/docs/asciidoc/_includes/reactive/webflux.adoc b/docs/manual/src/docs/asciidoc/_includes/reactive/webflux.adoc index e3fee04d43b..7cd91bb1922 100644 --- a/docs/manual/src/docs/asciidoc/_includes/reactive/webflux.adoc +++ b/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: diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc index ec2b8aa2599..eee0f8e6f48 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/anonymous.adoc +++ b/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. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/cas.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/cas.adoc index 704d92bb7e3..29c245eb950 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/cas.adoc +++ b/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. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/jaas.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/jaas.adoc index 8831c68cfe8..216435bf432 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/jaas.adoc +++ b/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`. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc index e26ca53fa38..b2375d62cbf 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/rememberme.adoc +++ b/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 <>. `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. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc index 9cf5c5f6b7e..bee0394d4be 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/session-management.adoc +++ b/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 <> chapter for additional information. === SessionManagementFilter diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/acls.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/acls.adoc index 4fe20450fbd..32ef05e387e 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/acls.adoc +++ b/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. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc index 240727384a7..25bf39f375e 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/architecture.adoc @@ -8,7 +8,7 @@ == Authorities <>, 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. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/secure-objects.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/secure-objects.adoc index 7370a4202ce..3182ac322f9 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authorization/secure-objects.adoc +++ b/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 <>. 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 `` or `` 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`. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/exploits/firewall.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/exploits/firewall.adoc index 2ee891dc023..7560afd6f0a 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/exploits/firewall.adoc +++ b/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 ==== diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-resourceserver.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-resourceserver.adoc index 349a6591fa3..c57881a2692 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-resourceserver.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/oauth2/oauth2-resourceserver.adoc @@ -192,7 +192,7 @@ This property can also be supplied directly on the <> 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 <` s>>, <` s>>, and <` metadata>>. +Then, you can provide this resolver to the appropriate filters that <``s>>, <``s>>, and <` 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 `` s +=== Producing ````s As stated earlier, Spring Security's SAML 2.0 support produces a `` to commence authentication with the asserting party. @@ -1103,7 +1103,7 @@ class AuthnRequestConverter : Converter` s +=== Authenticating ````s To verify SAML 2.0 Responses, Spring Security uses <> 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 `` and `` conditions -2. Validate `` s, expect for any IP address information +2. Validate ````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. From 44ad82e49d5d56c07c2e820184678a6fb1b2fae1 Mon Sep 17 00:00:00 2001 From: Dmitriy Bogdanov Date: Wed, 15 Sep 2021 13:37:26 +0400 Subject: [PATCH 3/3] Fix some list punctuation and capitalization in docs --- .../about/authentication/password-storage.adoc | 2 +- .../architecture/authentication.adoc | 2 +- .../_includes/servlet/authentication/index.adoc | 16 ++++++++-------- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc b/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc index 94eda552824..dcbf3ab8ad3 100644 --- a/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/about/authentication/password-storage.adoc @@ -55,7 +55,7 @@ Based upon the <> sect However, this ignores three real world problems: - There are many applications using old password encodings that cannot easily migrate -- The best practice for password storage will change again. +- The best practice for password storage will change again - As a framework Spring Security cannot make breaking changes frequently Instead Spring Security introduces `DelegatingPasswordEncoder` which solves all of the problems by: diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/authentication.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/authentication.adoc index 2e7319c4aec..878ecc24817 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/authentication.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/authentication.adoc @@ -12,7 +12,7 @@ The `Authentication` contains: * `principal` - identifies the user. When authenticating with a username/password this is often an instance of <>. -* `credentials` - Often a password. +* `credentials` - often a password. In many cases this will be cleared after the user is authenticated to ensure it is not leaked. * `authorities` - the <> are high level permissions the user is granted. A few examples are roles or scopes. diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/index.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/index.adoc index 9536e950e68..abd8e400c4c 100644 --- a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/index.adoc +++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/index.adoc @@ -10,12 +10,12 @@ This section discusses: This section describes the main architectural components of Spring Security's used in Servlet authentication. If you need concrete flows that explain how these pieces fit together, look at the <> specific sections. -* <> - The `SecurityContextHolder` is where Spring Security stores the details of who is <>. +* <> - the `SecurityContextHolder` is where Spring Security stores the details of who is <>. * <> - is obtained from the `SecurityContextHolder` and contains the `Authentication` of the currently authenticated user. -* <> - Can be the input to `AuthenticationManager` to provide the credentials a user has provided to authenticate or the current user from the `SecurityContext`. -* <> - An authority that is granted to the principal on the `Authentication` (i.e. roles, scopes, etc.) -* <> - the API that defines how Spring Security's Filters perform <>. -* <> - the most common implementation of `AuthenticationManager`. +* <> - can be the input to `AuthenticationManager` to provide the credentials a user has provided to authenticate or the current user from the `SecurityContext`. +* <> - an authority that is granted to the principal on the `Authentication` (i.e. roles, scopes, etc.) +* <> - the API that defines how Spring Security's Filters perform <>. +* <> - the most common implementation of `AuthenticationManager`. * <> - used by `ProviderManager` to perform a specific type of authentication. * <> - used for requesting credentials from a client (i.e. redirecting to a log in page, sending a `WWW-Authenticate` response, etc.) * <> - a base `Filter` used for authentication. @@ -30,10 +30,10 @@ This also gives a good idea of the high level flow of authentication and how pie * <> - OAuth 2.0 Log In with OpenID Connect and non-standard OAuth 2.0 Login (i.e. GitHub) * <> - SAML 2.0 Log In * <> - Central Authentication Server (CAS) Support -* <> - How to remember a user past session expiration -* <> - Authenticate with JAAS +* <> - how to remember a user past session expiration +* <> - authenticate with JAAS * <> - OpenID Authentication (not to be confused with OpenID Connect) -* <> - Authenticate with an external mechanism such as https://www.siteminder.com/[SiteMinder] or Java EE security but still use Spring Security for authorization and protection against common exploits. +* <> - authenticate with an external mechanism such as https://www.siteminder.com/[SiteMinder] or Java EE security but still use Spring Security for authorization and protection against common exploits. * <> - X509 Authentication // FIXME: Add other mechanisms