Fix some typos and mistakes in docs
This commit is contained in:
Dmitriy Bogdanov
Josh Cummings
parent
194993ad1a
commit
af4cc03dec
|
|
@ -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 <<authentication-password-storage-configuration,exposing a `NoOpPasswordEncoder` bean>>.
|
||||
|
|
|
|||
|
|
@ -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]]
|
||||
|
|
|
|||
|
|
@ -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 <<servlet-headers-custom,servlet>> based applications.
|
||||
Refer to the relevant section to see how to configure <<servlet-headers-custom,servlet>> based applications.
|
||||
====
|
||||
|
||||
Spring Security has mechanisms to make it convenient to add the more common security headers to your application.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Spring Security provides support for <<headers-hsts,Strict Transport Security>>
|
|||
== 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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 <<servlet-authentication-securitycontextholder>> is cleared out
|
||||
** The <<servlet-authentication-securitycontextholder>> 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
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 <<ns-config,namespace configuration>>, you can enable remember-me authentication just by adding the `<remember-me>` element:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,<<session-mgmt,as described earlier>>.
|
||||
The latter is also used when configuring an invalid session URL through the namespace, <<session-mgmt,as described earlier>>.
|
||||
|
||||
|
||||
=== SessionAuthenticationStrategy
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ The figure builds off our <<servlet-securityfilterchain,`SecurityFilterChain`>>
|
|||
image:{icondir}/number_1.png[] When the user submits their username and password, the `BasicAuthenticationFilter` creates a `UsernamePasswordAuthenticationToken` which is a type of <<servlet-authentication-authentication,`Authentication`>> 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 <<servlet-authentication-unpwd-storage,user information is stored>>.
|
||||
The details of what `AuthenticationManager` looks like depend on how the <<servlet-authentication-unpwd-storage,user information is stored>>.
|
||||
|
||||
image:{icondir}/number_3.png[] If authentication fails, then __Failure__
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ The figure builds off our <<servlet-securityfilterchain,`SecurityFilterChain`>>
|
|||
image:{icondir}/number_1.png[] When the user submits their username and password, the `UsernamePasswordAuthenticationFilter` creates a `UsernamePasswordAuthenticationToken` which is a type of <<servlet-authentication-authentication,`Authentication`>> 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 <<servlet-authentication-unpwd-storage,user information is stored>>.
|
||||
The details of what `AuthenticationManager` looks like depend on how the <<servlet-authentication-unpwd-storage,user information is stored>>.
|
||||
|
||||
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
|
||||
====
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
[[servlet-authentication-inmemory]]
|
||||
= In-Memory Authentication
|
||||
|
||||
Spring Security's `InMemoryUserDetailsManager` implements <<servlet-authentication-userdetailsservice,UserDetailsService>> to provide support for username/password based authentication that is retrieved in memory.
|
||||
Spring Security's `InMemoryUserDetailsManager` implements <<servlet-authentication-userdetailsservice,UserDetailsService>> 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 <<servlet-authentication-unpwd-input,accept a username/password>> for authentication.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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 <<el-permission-evaluator,see below>>.
|
||||
You can access any of the method arguments by name as expression variables.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 `<saml2:LogoutRequest>`
|
||||
* AP-initiated logout, which allows an asserting party to send a `<saml2:LogoutRequest>` to the application
|
||||
* AP logout response, which allows an asserting party to send a `<saml2:LogoutResponse>` in response to the RP-initiated `<saml2:LogoutRequest>`
|
||||
|
|
|
|||
Loading…
Reference in New Issue