Fix Asciidoctor Warnings

Closes gh-7973
This commit is contained in:
Rob Winch 2020-02-10 10:47:21 -06:00
parent 5bdf57d1e5
commit 2909d46060
23 changed files with 107 additions and 100 deletions

View File

@ -51,7 +51,7 @@ The short term credential can be validated quickly without any loss in security.
== DelegatingPasswordEncoder
Prior to Spring Security 5.0 the default `PasswordEncoder` was `NoOpPasswordEncoder` which required plain text passwords.
Based upon the <<password-history,Password History>> section you might expect that the default `PasswordEncoder` is now something like `BCryptPasswordEncoder`.
Based upon the <<authentication-password-storage-history,Password History>> section you might expect that the default `PasswordEncoder` is now something like `BCryptPasswordEncoder`.
However, this ignores three real world problems:
- There are many applications using old password encodings that cannot easily migrate
@ -101,7 +101,7 @@ The general format for a password is:
.DelegatingPasswordEncoder Storage Format
====
[source,text]
[source,text,attrs="-attributes"]
----
{id}encodedPassword
----
@ -115,7 +115,7 @@ All of the original passwords are "password".
.DelegatingPasswordEncoder Encoded Passwords Example
====
[source,text]
[source,text,attrs="-attributes"]
----
{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG // <1>
{noop}password // <2>
@ -148,12 +148,12 @@ For example, BCrypt passwords often start with `$2a$`.
=== Password Encoding
The `idForEncode` passed into the constructor determines which `PasswordEncoder` will be used for encoding passwords.
In the `DelegatingPasswordEncoder` we constructed above, that means that the result of encoding `password` would be delegated to `BCryptPasswordEncoder` and be prefixed with `{bcrypt}`.
In the `DelegatingPasswordEncoder` we constructed above, that means that the result of encoding `password` would be delegated to `BCryptPasswordEncoder` and be prefixed with `+{bcrypt}+`.
The end result would look like:
.DelegatingPasswordEncoder Encode Example
====
[source,text]
[source,text,attrs="-attributes"]
----
{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
----
@ -162,7 +162,7 @@ The end result would look like:
[[authentication-password-storage-dpe-matching]]
=== Password Matching
Matching is done based upon the `{id}` and the mapping of the `id` to the `PasswordEncoder` provided in the constructor.
Matching is done based upon the `+{id}+` and the mapping of the `id` to the `PasswordEncoder` provided in the constructor.
Our example in <<authentication-password-storage-dpe-format,Password Storage Format>> provides a working example of how this is done.
By default, the result of invoking `matches(CharSequence, String)` with a password and an `id` that is not mapped (including a null id) will result in an `IllegalArgumentException`.
This behavior can be customized using `DelegatingPasswordEncoder.setDefaultPasswordEncoderForMatches(PasswordEncoder)`.
@ -180,7 +180,7 @@ There are convenience mechanisms to make this easier, but this is still not inte
.withDefaultPasswordEncoder Example
====
[source,java]
[source,java,attrs="-attributes"]
----
User user = User.withDefaultPasswordEncoder()
.username("user")
@ -225,7 +225,7 @@ For example, the following will encode the password of `password` for use with <
.Spring Boot CLI encodepassword Example
====
[source]
[source,attrs="-attributes"]
----
spring encodepassword password
{bcrypt}$2a$10$X5wFBtLrL/kHcmrOGGTrGufsBX8CJ0WpQpF3pgeuxBB/H73BK1DW6
@ -235,7 +235,7 @@ spring encodepassword password
[[authentication-password-storage-dpe-troubleshoot]]
=== Troubleshooting
The following error occurs when one of the passwords that are stored has no id as described in <<pe-dpe-format>>.
The following error occurs when one of the passwords that are stored has no id as described in <<authentication-password-storage-dpe-format>>.
----
java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"
@ -257,6 +257,8 @@ $2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
to
[source,attrs="-attributes"]
----
{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
----

View File

@ -276,7 +276,7 @@ dependencies {
If you use additional features (such as LDAP, OpenID, and others), you need to also include the appropriate <<modules>>.
Spring Security builds against Spring Framework {spring-core-version} but should generally work with any newer version of Spring Framework 5.x. {JB}
Spring Security builds against Spring Framework {spring-core-version} but should generally work with any newer version of Spring Framework 5.x.
Many users are likely to run afoul of the fact that Spring Security's transitive dependencies resolve Spring Framework {spring-core-version}, which can cause strange classpath problems.
The easiest way to resolve this is to use the `spring-framework-bom` within your `<dependencyManagement>` section of your `pom.xml`.
You can do so by using the https://github.com/spring-gradle-plugins/dependency-management-plugin[Dependency Management Plugin], as the following example shows:

View File

@ -1,3 +1,4 @@
[[samples]]
= Samples
Spring Security includes many {gh-samples-url}[samples] applications.

View File

@ -83,7 +83,7 @@ In order for the <<csrf-protection-stp,synchronizer token pattern>> to protect a
This must be included in a part of the request (i.e. form parameter, HTTP header, etc) that is not automatically included in the HTTP request by the browser.
Spring Security's https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/server/csrf/CsrfWebFilter.html[CsrfWebFilter] exposes a https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/csrf/CsrfToken.html[Mono<CsrfToken>] as a `ServerWebExchange` attribute named `org.springframework.security.web.server.csrf.CsrfToken`.
This means that any view technology can access the `Mono<CsrfToken>` to expose the expected token as either a <<webflux-csrf-include-form-attr,form>> or <<webflux-csrf-include-ajax-meta-attr,meta tag>>.
This means that any view technology can access the `Mono<CsrfToken>` to expose the expected token as either a <<webflux-csrf-include-form-attr,form>> or <<webflux-csrf-include-ajax-meta,meta tag>>.
[[webflux-csrf-include-subscribe]]
If your view technology does not provide a simple way to subscribe to the `Mono<CsrfToken>`, a common pattern is to use Spring's `@ControllerAdvice` to expose the `CsrfToken` directly.

View File

@ -54,4 +54,4 @@ Spring Security provides support for <<servlet-headers-hsts,Strict Transport Sec
[[webflux-http-proxy-server]]
== Proxy Server Configuration
Spring Security <<http-proxy-servers,integrates with proxy servers>>.
Spring Security <<http-proxy-server,integrates with proxy servers>>.

View File

@ -38,11 +38,11 @@ The redirect URI is the path in the application that the end-user's user-agent i
In the "Set a redirect URI" sub-section, ensure that the *Authorized redirect URIs* field is set to `http://localhost:8080/login/oauth2/code/google`.
TIP: The default redirect URI template is `{baseUrl}/login/oauth2/code/{registrationId}`.
The *_registrationId_* is a unique identifier for the <<jc-oauth2login-client-registration,ClientRegistration>>.
TIP: The default redirect URI template is `+{baseUrl}/login/oauth2/code/{registrationId}+`.
The *_registrationId_* is a unique identifier for the <<oauth2Client-client-registration,ClientRegistration>>.
For our example, the `registrationId` is `google`.
IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<appendix-proxy-server, Proxy Server Configuration>> to ensure the application is correctly configured.
IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<http-proxy-server,Proxy Server Configuration>> to ensure the application is correctly configured.
Also, see the supported <<oauth2Client-auth-code-redirect-uri, `URI` template variables>> for `redirect-uri`.
[[webflux-oauth2-login-sample-config]]
@ -68,7 +68,7 @@ spring:
.OAuth Client properties
====
<1> `spring.security.oauth2.client.registration` is the base property prefix for OAuth Client properties.
<2> Following the base property prefix is the ID for the <<jc-oauth2login-client-registration,ClientRegistration>>, such as google.
<2> Following the base property prefix is the ID for the <<oauth2Client-client-registration,ClientRegistration>>, such as google.
====
. Replace the values in the `client-id` and `client-secret` property with the OAuth 2.0 credentials you created earlier.

View File

@ -117,7 +117,7 @@ We still specify the `issuer-uri` so that Resource Server still validates the `i
[NOTE]
This property can also be supplied directly on the <<webflux-oauth2resourceserver-jwt-jwkseturi-dsl,DSL>>.
[[webflux-oauth2resourceserver-sansboot]]
[[webflux-oauth2resourceserver-jwt-sansboot]]
=== Overriding or Replacing Boot Auto Configuration
There are two `@Bean` s that Spring Boot generates on Resource Server's behalf.
@ -559,6 +559,7 @@ This can be handy when revocation is a requirement.
When using https://spring.io/projects/spring-boot[Spring Boot], configuring an application as a resource server that uses introspection consists of two basic steps.
First, include the needed dependencies and second, indicate the introspection endpoint details.
[[webflux-oauth2resourceserver-opaque-introspectionuri]]
==== Specifying the Authorization Server
To specify where the introspection endpoint is, simply do:
@ -1005,7 +1006,7 @@ ReactiveOpaqueTokenIntrospector introspector() {
}
----
[[oauth2resourceserver-multitenancy]]
[[webflux-oauth2resourceserver-multitenancy]]
== Multi-tenancy
A resource server is considered multi-tenant when there are multiple strategies for verifying a bearer token, keyed by some tenant identifier.

View File

@ -1248,7 +1248,7 @@ By default, an instance of `PortMapperImpl` will be added to the configuration f
This element can optionally be used to override the default mappings which that class defines.
Each child `<port-mapping>` element defines a pair of HTTP:HTTPS ports.
The default mappings are 80:443 and 8080:8443.
An example of overriding these can be found in the <<ns-requires-channel,namespace introduction>>.
An example of overriding these can be found in <<servlet-http-redirect>>.
[[nsa-port-mappings-parents]]
@ -1751,7 +1751,7 @@ All elements which create `AuthenticationProvider` instances should be children
[[nsa-authentication-manager-alias]]
* **alias**
This attribute allows you to define an alias name for the internal instance for use in your own configuration.
Its use is described in the<<ns-auth-manager,namespace introduction>>.
Its use is described in the <<ns-auth-manager,namespace introduction>>.
[[nsa-authentication-manager-erase-credentials]]
@ -1912,7 +1912,7 @@ select username, password, enabled from users where username = ?
[[nsa-password-encoder]]
==== <password-encoder>
Authentication providers can optionally be configured to use a password encoder as described in the <<ns-password-encoder,namespace introduction>>.
Authentication providers can optionally be configured to use a password encoder as described in the <<authentication-password-storage>>.
This will result in the bean being injected with the appropriate `PasswordEncoder` instance.
@ -2338,7 +2338,7 @@ A method name
[[nsa-ldap]]
=== LDAP Namespace Options
LDAP is covered in some details in <<ldap,its own chapter>>.
LDAP is covered in some details in <<servlet-authentication-ldap,its own chapter>>.
We will expand on that here with some explanation of how the namespace options map to Spring beans.
The LDAP implementation uses Spring LDAP extensively, so some familiarity with that project's API may be useful.
@ -2348,7 +2348,7 @@ The LDAP implementation uses Spring LDAP extensively, so some familiarity with t
`<ldap-server>` Element
This element sets up a Spring LDAP `ContextSource` for use by the other LDAP beans, defining the location of the LDAP server and other information (such as a username and password, if it doesn't allow anonymous access) for connecting to it.
It can also be used to create an embedded server for testing.
Details of the syntax for both options are covered in the <<ldap-server,LDAP chapter>>.
Details of the syntax for both options are covered in the <<servlet-authentication-ldap,LDAP chapter>>.
The actual `ContextSource` implementation is `DefaultSpringSecurityContextSource` which extends Spring LDAP's `LdapContextSource` class.
The `manager-dn` and `manager-password` attributes map to the latter's `userDn` and `password` properties respectively.
@ -2443,7 +2443,7 @@ Defaults to "" (searching from the root).
* **group-search-filter**
Group search filter.
Maps to the ``DefaultLdapAuthoritiesPopulator``'s `groupSearchFilter` property.
Defaults to (uniqueMember={0}).
Defaults to `+(uniqueMember={0})+`.
The substituted parameter is the DN of the user.
@ -2476,8 +2476,8 @@ If set, the framework will attempt to load standard attributes for the defined c
* **user-dn-pattern**
If your users are at a fixed location in the directory (i.e. you can work out the DN directly from the username without doing a directory search), you can use this attribute to map directly to the DN.
It maps directly to the `userDnPatterns` property of `AbstractLdapAuthenticator`.
The value is a specific pattern used to build the user's DN, for example "uid={0},ou=people".
The key "{0}" must be present and will be substituted with the username.
The value is a specific pattern used to build the user's DN, for example `+uid={0},ou=people+`.
The key `+{0}+` must be present and will be substituted with the username.
[[nsa-ldap-authentication-provider-user-search-base]]
@ -2490,20 +2490,20 @@ Only used with a 'user-search-filter'.
If you need to perform a search to locate the user in the directory, then you can set these attributes to control the search.
The `BindAuthenticator` will be configured with a `FilterBasedLdapUserSearch` and the attribute values map directly to the first two arguments of that bean's constructor.
If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `user-search-filter="(uid={0})"` and `user-search-base=""` will be used.
If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `+user-search-filter="(uid={0})"+` and `user-search-base=""` will be used.
[[nsa-ldap-authentication-provider-user-search-filter]]
* **user-search-filter**
The LDAP filter used to search for users (optional).
For example "(uid={0})".
For example `+(uid={0})+`.
The substituted parameter is the user's login name.
+
If you need to perform a search to locate the user in the directory, then you can set these attributes to control the search.
The `BindAuthenticator` will be configured with a `FilterBasedLdapUserSearch` and the attribute values map directly to the first two arguments of that bean's constructor.
If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `user-search-filter="(uid={0})"` and `user-search-base=""` will be used.
If these attributes aren't set and no `user-dn-pattern` has been supplied as an alternative, then the default search values of `+user-search-filter="(uid={0})"+` and `user-search-base=""` will be used.
[[nsa-ldap-authentication-provider-children]]
@ -2582,7 +2582,7 @@ Defaults to "" (searching from the root).
[[nsa-ldap-user-service-group-search-filter]]
* **group-search-filter**
Group search filter.
Defaults to (uniqueMember={0}).
Defaults to `+(uniqueMember={0})+`.
The substituted parameter is the DN of the user.
@ -2625,5 +2625,5 @@ Only used with a 'user-search-filter'.
[[nsa-ldap-user-service-user-search-filter]]
* **user-search-filter**
The LDAP filter used to search for users (optional).
For example "(uid={0})".
For example `+(uid={0})+`.
The substituted parameter is the user's login name.

View File

@ -79,7 +79,7 @@ Configuring the provider is quite simple:
The `PasswordEncoder` is optional.
A `PasswordEncoder` provides encoding and matching of encoded passwords presented in the `UserDetails` object that is returned from the configured `UserDetailsService`.
This will be discussed in more detail <<core-services-password-encoding,below>>.
This is discussed in more detail in <<authentication-password-storage>>.
=== UserDetailsService Implementations
@ -105,7 +105,7 @@ Is easy to use create a custom `UserDetailsService` implementation that extracts
This is particularly true if you're building a prototype application or just starting integrating Spring Security, when you don't really want to spend time configuring databases or writing `UserDetailsService` implementations.
For this sort of situation, a simple option is to use the `user-service` element from the security <<ns-minimal,namespace>>:
[source,xml]
[source,xml,attrs="-attributes"]
----
<user-service id="userDetailsService">
<!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that

View File

@ -168,4 +168,8 @@ Below is a comprehensive list of Spring Security Filter ordering:
include::technical-overview.adoc[]
include::security-filter-chain.adoc[]
include::core-filters.adoc[]
include::core-services.adoc[]

View File

@ -19,7 +19,7 @@ public SpringAuthenticationProvider springAuthenticationProvider() {
=== AuthenticationProvider XML Configuration
In practice you will need a more scalable source of user information than a few names added to the application context file.
Most likely you will want to store your user information in something like a database or an LDAP server.
LDAP namespace configuration is dealt with in the <<ldap,LDAP chapter>>, so we won't cover it here.
LDAP namespace configuration is dealt with in the <<servlet-authentication-ldap,LDAP chapter>>, so we won't cover it here.
If you have a custom implementation of Spring Security's `UserDetailsService`, called "myUserDetailsService" in your application context, then you can authenticate against this using
[source,xml]

View File

@ -92,7 +92,7 @@ The web application side of CAS is made easy due to Spring Security.
It is assumed you already know the basics of using Spring Security, so these are not covered again below.
We'll assume a namespace based configuration is being used and add in the CAS beans as required.
Each section builds upon the previous section.
A full<<cas-sample,CAS sample application>> can be found in the Spring Security Samples.
A full CAS sample application can be found in the Spring Security <<samples,Samples>>.
[[cas-st]]
@ -148,7 +148,7 @@ You can use these properties to customize things like behavior for authenticatio
Next you need to add a `CasAuthenticationProvider` and its collaborators:
[source,xml]
[source,xml,attrs="-attributes"]
----
<security:authentication-manager alias="authenticationManager">
<security:authentication-provider ref="casAuthenticationProvider" />
@ -337,7 +337,7 @@ An example configuration is shown below.
[[cas-pt-client-sample]]
===== Calling a Stateless Service Using a Proxy Ticket
Now that Spring Security obtains PGTs, you can use them to create proxy tickets which can be used to authenticate to a stateless service.
The <<cas-sample,CAS sample application>> contains a working example in the `ProxyTicketSampleServlet`.
The CAS <<samples,sample application>> contains a working example in the `ProxyTicketSampleServlet`.
Example code can be found below:
[source,java]

View File

@ -1,5 +1,4 @@
[[session-mgmt]]
[[ns-session-mgmt]]
== Session Management
HTTP session related functionality is handled by a combination of the `SessionManagementFilter` and the `SessionAuthenticationStrategy` interface, which the filter delegates to.
Typical usage includes session-fixation protection attack prevention, detection of session timeouts and restrictions on how many sessions an authenticated user may have open concurrently.
@ -126,7 +125,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,<<ns-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

View File

@ -5,12 +5,12 @@ Spring Security's `InMemoryUserDetailsManager` implements <<servlet-authenticati
`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.
In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW`.
In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
.InMemoryUserDetailsManager Java Configuration
====
.Java
[source,java,role="primary"]
[source,java,role="primary",attrs="-attributes"]
----
@Bean
public UserDetailsService users() {
@ -29,7 +29,7 @@ public UserDetailsService users() {
----
.XML
[source,xml,role="secondary"]
[source,xml,role="secondary",attrs="-attributes"]
----
<user-service>
<user name="user"
@ -42,7 +42,7 @@ public UserDetailsService users() {
----
.Kotlin
[source,kotlin,role="secondary"]
[source,kotlin,role="secondary,attrs="-attributes""]
----
@Bean
fun users(): UserDetailsService {
@ -114,11 +114,11 @@ fun users(): UserDetailsService {
====
There is no simple way to use `User.withDefaultPasswordEncoder` with XML based configuration.
For demos or just getting started, you can choose to prefix the password with `{noop}` to indicate <<authentication-password-storage-dpe-format,no encoding should be used>>.
For demos or just getting started, you can choose to prefix the password with `+{noop}+` to indicate <<authentication-password-storage-dpe-format,no encoding should be used>>.
.<user-service> `{noop}` XML Configuration
.<user-service> `+{noop}+` XML Configuration
====
[source,xml]
[source,xml,attrs="-attributes"]
----
<user-service>
<user name="user"

View File

@ -147,14 +147,14 @@ In a production environment, you will want to ensure you setup a connection to a
[[servlet-authentication-jdbc-bean]]
== JdbcUserDetailsManager Bean
In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW`.
In this sample we use <<authentication-password-storage-boot-cli,Spring Boot CLI>> to encode the password of `password` and get the encoded password of `+{bcrypt}$2a$10$GRLdNijSQMUvl/au9ofL.eDwmoohzzS7.rmNSJZ.0FxO/BTk76klW+`.
See the <<authentication-password-storage,PasswordEncoder>> section for more details about how to store passwords.
.JdbcUserDetailsManager
====
.Java
[source,java,role="primary"]
[source,java,role="primary",attrs="-attributes"]
----
@Bean
UserDetailsManager users(DataSource dataSource) {
@ -174,7 +174,7 @@ UserDetailsManager users(DataSource dataSource) {
----
.XML
[source,xml,role="secondary"]
[source,xml,role="secondary",attrs="-attributes"]
----
<jdbc-user-service>
<user name="user"
@ -187,7 +187,7 @@ UserDetailsManager users(DataSource dataSource) {
----
.Kotlin
[source,kotlin,role="secondary"]
[source,kotlin,role="secondary",attrs="-attributes"]
----
@Bean
fun users(dataSource: DataSource): UserDetailsManager {

View File

@ -284,7 +284,7 @@ An example of bind authentication configuration can be found below.
.Bind Authentication
====
.Java
[source,java,role="primary"]
[source,java,role="primary",attrs="-attributes"]
----
@Bean
BindAuthenticator authenticator(BaseLdapPathContextSource contextSource) {
@ -300,14 +300,14 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
----
.XML
[source,xml,role="secondary"]
[source,xml,role="secondary",attrs="-attributes"]
----
<ldap-authentication-provider
user-dn-pattern="uid={0},ou=people"/>
----
.Kotlin
[source,kotlin,role="secondary"]
[source,kotlin,role="secondary",attrs="-attributes"]
----
@Bean
fun authenticator(contextSource: BaseLdapPathContextSource): BindAuthenticator {
@ -330,7 +330,7 @@ If instead you wished to configure an LDAP search filter to locate the user, you
.Bind Authentication with Search Filter
====
.Java
[source,java,role="primary"]
[source,java,role="primary",attrs="-attributes"]
----
@Bean
BindAuthenticator authenticator(BaseLdapPathContextSource contextSource) {
@ -350,7 +350,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
----
.XML
[source,xml,role="secondary"]
[source,xml,role="secondary",attrs="-attributes"]
----
<ldap-authentication-provider
user-search-filter="(uid={0})"
@ -358,7 +358,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
----
.Kotlin
[source,kotlin,role="secondary"]
[source,kotlin,role="secondary",attrs="-attributes"]
----
@Bean
fun authenticator(contextSource: BaseLdapPathContextSource): BindAuthenticator {
@ -377,7 +377,7 @@ fun authenticationProvider(authenticator: LdapAuthenticator): LdapAuthentication
----
====
If used with the `ContextSource` <<servlet-authentication-ldap-contextsource,definition above>>, this would perform a search under the DN `ou=people,dc=springframework,dc=org` using `(uid={0})` as a filter.
If used with the `ContextSource` <<servlet-authentication-ldap-contextsource,definition above>>, this would perform a search under the DN `ou=people,dc=springframework,dc=org` using `+(uid={0})+` as a filter.
Again the user login name is substituted for the parameter in the filter name, so it will search for an entry with the `uid` attribute equal to the user name.
If a user search base isn't supplied, the search will be performed from the root.
@ -405,7 +405,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
----
.XML
[source,xml,role="secondary"]
[source,xml,role="secondary",attrs="-attributes"]
----
<ldap-authentication-provider
user-dn-pattern="uid={0},ou=people">
@ -451,7 +451,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
----
.XML
[source,xml,role="secondary"]
[source,xml,role="secondary",attrs="-attributes"]
----
<ldap-authentication-provider
user-dn-pattern="uid={0},ou=people">
@ -492,7 +492,7 @@ Spring Security's `LdapAuthoritiesPopulator` is used to determine what authorite
.Minimal Password Compare Configuration
====
.Java
[source,java,role="primary"]
[source,java,role="primary",attrs="-attributes"]
----
@Bean
LdapAuthoritiesPopulator authorities(BaseLdapPathContextSource contextSource) {
@ -510,7 +510,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
----
.XML
[source,xml,role="secondary"]
[source,xml,role="secondary",attrs="-attributes"]
----
<ldap-authentication-provider
user-dn-pattern="uid={0},ou=people"
@ -518,7 +518,7 @@ LdapAuthenticationProvider authenticationProvider(LdapAuthenticator authenticato
----
.Kotlin
[source,kotlin,role="secondary"]
[source,kotlin,role="secondary",attrs="-attributes"]
----
@Bean
fun authorities(contextSource: BaseLdapPathContextSource): LdapAuthoritiesPopulator {

View File

@ -150,7 +150,7 @@ http
==== Path Variables in Web Security Expressions
At times it is nice to be able to refer to path variables within a URL.
For example, consider a RESTful application that looks up a user by id from the URL path in the format `/user/{userId}`.
For example, consider a RESTful application that looks up a user by id from the URL path in the format `+/user/{userId}+`.
You can easily refer to the path variable by placing it in the pattern.
For example, if you had a Bean with the name of `webSecurity` that contains the following method signature:
@ -166,7 +166,7 @@ public class WebSecurity {
You could refer to the method using:
[source,xml]
[source,xml,attrs="-attributes"]
----
<http>
<intercept-url pattern="/user/{userId}/**"
@ -177,7 +177,7 @@ You could refer to the method using:
or in Java configuration
[source,java]
[source,java,attrs="-attributes"]
----
http
.authorizeRequests(authorize -> authorize

View File

@ -55,4 +55,4 @@ Spring Security provides support for <<servlet-headers-hsts,Strict Transport Sec
[[servlet-http-proxy-server]]
== Proxy Server Configuration
Spring Security <<http-proxy-servers,integrates with proxy servers>>.
Spring Security <<http-proxy-server,integrates with proxy servers>>.

View File

@ -18,7 +18,7 @@ For example, adding the following element from the security namespace to an appl
This is much simpler than wiring up the equivalent Apache Directory Server beans.
The most common alternative configuration requirements are supported by attributes on the `ldap-server` element and the user is isolated from worrying about which beans they need to create and what the bean property names are.
footnote:[You can find out more about the use of the `ldap-server` element in the chapter on pass:specialcharacters,macros[<<ldap>>].].
footnote:[You can find out more about the use of the `ldap-server` element in the chapter on pass:specialcharacters,macros[<<servlet-authentication-ldap>>].].
Use of a good XML editor while editing the application context file should provide information on the attributes and elements that are available.
We would recommend that you try out the https://spring.io/tools/sts[Spring Tool Suite] as it has special features for working with standard Spring namespaces.
@ -148,7 +148,7 @@ You can also add a `method` attribute to limit the match to a particular HTTP me
To add some users, you can define a set of test data directly in the namespace:
[source,xml]
[source,xml,attrs="-attributes"]
----
<authentication-manager>
<authentication-provider>
@ -164,9 +164,9 @@ To add some users, you can define a set of test data directly in the namespace:
----
This is an example of a secure way of storing the same passwords.
The password is prefixed with `{bcrypt}` to instruct `DelegatingPasswordEncoder`, which supports any configured `PasswordEncoder` for matching, that the passwords are hashed using BCrypt:
The password is prefixed with `+{bcrypt}+` to instruct `DelegatingPasswordEncoder`, which supports any configured `PasswordEncoder` for matching, that the passwords are hashed using BCrypt:
[source,xml]
[source,xml,attrs="-attributes"]
----
<authentication-manager>
<authentication-provider>

View File

@ -364,11 +364,11 @@ Please refer to the https://tools.ietf.org/html/rfc6749#section-4.1.1[Authorizat
The `OAuth2AuthorizationRequestRedirectFilter` uses an `OAuth2AuthorizationRequestResolver` to resolve an `OAuth2AuthorizationRequest` and initiate the Authorization Code grant flow by redirecting the end-user's user-agent to the Authorization Server's Authorization Endpoint.
The primary role of the `OAuth2AuthorizationRequestResolver` is to resolve an `OAuth2AuthorizationRequest` from the provided web request.
The default implementation `DefaultOAuth2AuthorizationRequestResolver` matches on the (default) path `/oauth2/authorization/{registrationId}` extracting the `registrationId` and using it to build the `OAuth2AuthorizationRequest` for the associated `ClientRegistration`.
The default implementation `DefaultOAuth2AuthorizationRequestResolver` matches on the (default) path `+/oauth2/authorization/{registrationId}+` extracting the `registrationId` and using it to build the `OAuth2AuthorizationRequest` for the associated `ClientRegistration`.
Given the following Spring Boot 2.x properties for an OAuth 2.0 Client registration:
[source,yaml]
[source,yaml,attrs="-attributes"]
----
spring:
security:
@ -395,7 +395,7 @@ which also initiates the Authorization Request redirect by the `OAuth2Authorizat
If the OAuth 2.0 Client is a https://tools.ietf.org/html/rfc6749#section-2.1[Public Client], then configure the OAuth 2.0 Client registration as follows:
[source,yaml]
[source,yaml,attrs="-attributes"]
----
spring:
security:
@ -421,7 +421,7 @@ The `DefaultOAuth2AuthorizationRequestResolver` also supports `URI` template var
The following configuration uses all the supported `URI` template variables:
[source,yaml]
[source,yaml,attrs="-attributes"]
----
spring:
security:
@ -435,9 +435,9 @@ spring:
----
[NOTE]
`{baseUrl}` resolves to `{baseScheme}://{baseHost}{basePort}{basePath}`
`+{baseUrl}+` resolves to `+{baseScheme}://{baseHost}{basePort}{basePath}+`
Configuring the `redirect-uri` with `URI` template variables is especially useful when the OAuth 2.0 Client is running behind a <<appendix-proxy-server, Proxy Server>>.
Configuring the `redirect-uri` with `URI` template variables is especially useful when the OAuth 2.0 Client is running behind a <<http-proxy-server,Proxy Server>>.
This ensures that the `X-Forwarded-*` headers are used when expanding the `redirect-uri`.
===== Customizing the Authorization Request

View File

@ -39,10 +39,10 @@ The redirect URI is the path in the application that the end-user's user-agent i
In the "Set a redirect URI" sub-section, ensure that the *Authorized redirect URIs* field is set to `http://localhost:8080/login/oauth2/code/google`.
TIP: The default redirect URI template is `{baseUrl}/login/oauth2/code/{registrationId}`.
TIP: The default redirect URI template is `+{baseUrl}/login/oauth2/code/{registrationId}+`.
The *_registrationId_* is a unique identifier for the <<oauth2Client-client-registration,ClientRegistration>>.
IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<appendix-proxy-server, Proxy Server Configuration>> to ensure the application is correctly configured.
IMPORTANT: If the OAuth Client is running behind a proxy server, it is recommended to check <<http-proxy-server,Proxy Server Configuration>> to ensure the application is correctly configured.
Also, see the supported <<oauth2Client-auth-code-redirect-uri, `URI` template variables>> for `redirect-uri`.
@ -248,7 +248,7 @@ If you need to override the auto-configuration based on your specific requiremen
The following example shows how to register a `ClientRegistrationRepository` `@Bean`:
[source,java]
[source,java,attrs="-attributes"]
----
@Configuration
public class OAuth2LoginConfig {
@ -305,7 +305,7 @@ public class OAuth2LoginSecurityConfig extends WebSecurityConfigurerAdapter {
The following example shows how to completely override the auto-configuration by registering a `ClientRegistrationRepository` `@Bean` and providing a `WebSecurityConfigurerAdapter`.
[source,java]
[source,java,attrs="-attributes"]
----
@Configuration
public class OAuth2LoginConfig {
@ -508,7 +508,7 @@ See `InMemoryClientRegistrationRepository` for reference.
The link's destination for each OAuth Client defaults to the following:
`OAuth2AuthorizationRequestRedirectFilter.DEFAULT_AUTHORIZATION_REQUEST_BASE_URI` + "/{registrationId}"
`+OAuth2AuthorizationRequestRedirectFilter.DEFAULT_AUTHORIZATION_REQUEST_BASE_URI + "/{registrationId}"+`
The following line shows an example:
@ -595,7 +595,7 @@ You also need to ensure the `ClientRegistration.redirectUriTemplate` matches the
The following listing shows an example:
[source,java]
[source,java,attrs="-attributes"]
----
return CommonOAuth2Provider.GOOGLE.getBuilder("google")
.clientId("google-client-id")

View File

@ -709,6 +709,7 @@ This can be handy when revocation is a requirement.
When using https://spring.io/projects/spring-boot[Spring Boot], configuring an application as a resource server that uses introspection consists of two basic steps.
First, include the needed dependencies and second, indicate the introspection endpoint details.
[[oauth2resourceserver-opaque-introspectionuri]]
==== Specifying the Authorization Server
To specify where the introspection endpoint is, simply do:

View File

@ -46,8 +46,8 @@ the IDP sends an assertion to the SP.
[[samllogin-feature-set]]
=== Saml 2 Login - Current Feature Set
1. Service Provider (SP/Relying Party) is identified by `entityId = {baseUrl}/saml2/service-provider-metadata/{registrationId}`
2. Receive assertion embedded in a SAML response via Http-POST or Http-Redirect at `{baseUrl}/login/saml2/sso/{registrationId}`
1. Service Provider (SP/Relying Party) is identified by `+entityId = {baseUrl}/saml2/service-provider-metadata/{registrationId}+`
2. Receive assertion embedded in a SAML response via Http-POST or Http-Redirect at `+{baseUrl}/login/saml2/sso/{registrationId}+`
3. Requires the assertion to be signed, unless the response is signed
4. Supports encrypted assertions
5. Supports encrypted NameId elements
@ -131,9 +131,7 @@ an incoming request. The URI patterns in `saml2Login` can contain the following
* `basePort`
For example:
```
{baseUrl}/login/saml2/sso/{registrationId}
```
`+{baseUrl}/login/saml2/sso/{registrationId}+`
===== Relying Party
@ -141,7 +139,7 @@ For example:
* `registrationId` - (required) a unique identifer for this configuration mapping.
This identifier may be used in URI paths, so care should be taken that no URI encoding is required.
* `localEntityIdTemplate` - (optional) A URI pattern that creates an entity ID for this application based on the incoming request. The default is
`{baseUrl}/saml2/service-provider-metadata/{registrationId}` and for a small sample application
`+{baseUrl}/saml2/service-provider-metadata/{registrationId}+` and for a small sample application
it would look like
```
http://localhost:8080/saml2/service-provider-metadata/my-test-configuration
@ -153,7 +151,7 @@ no patterns allowed.
* `assertionConsumerServiceUrlTemplate` - (optional) A URI pattern that denotes the assertion
consumer service URI to be sent with any `AuthNRequest` from the SP to the IDP during the SP initiated flow.
While this can be a pattern the actual URI must resolve to the ACS endpoint on the SP.
The default value is `{baseUrl}/login/saml2/sso/{registrationId}` and maps directly to the
The default value is `+{baseUrl}/login/saml2/sso/{registrationId}+` and maps directly to the
https://github.com/spring-projects/spring-security/blob/5.2.0.RELEASE/saml2/saml2-service-provider/src/main/java/org/springframework/security/saml2/provider/service/servlet/filter/Saml2WebSsoAuthenticationFilter.java#L42[`Saml2WebSsoAuthenticationFilter`] endpoint
* `idpWebSsoUrl` - (required) a fixed URI value for the IDP Single Sign On endpoint where
the SP sends the `AuthNRequest` messages.
@ -198,10 +196,10 @@ credentials on all the identity providers.
The Spring Security SAML 2 implementation does not yet provide an endpoint for downloading
SP metadata in XML format. The minimal pieces that are exchanged
* *entity ID* - defaults to `{baseUrl}/saml2/service-provider-metadata/{registrationId}`
* *entity ID* - defaults to `+{baseUrl}/saml2/service-provider-metadata/{registrationId}+`
Other known configuration names that also use this same value
** Audience Restriction
* *single signon URL* - defaults to `{baseUrl}/login/saml2/sso/{registrationId}`
* *single signon URL* - defaults to `+{baseUrl}/login/saml2/sso/{registrationId}+`
Other known configuration names that also use this same value
** Recipient URL
** Destination URL
@ -212,9 +210,9 @@ credentials must be shared with the Identity Provider
==== Authentication Requests - SP Initiated Flow
To initiate an authentication from the web application, a simple redirect to
```
{baseUrl}/saml2/authenticate/{registrationId}
```
`+{baseUrl}/saml2/authenticate/{registrationId}+`
The endpoint will generate an `AuthNRequest` by invoking the `createAuthenticationRequest` method on a
configurable factory. Just expose the `Saml2AuthenticationRequestFactory` as a bean in your configuration.
[source,java]
@ -345,9 +343,7 @@ To run the sample, follow these three steps
It's very simple to use multiple providers, but there are some defaults that
may trip you up if you don't pay attention. In our SAML configuration of
`RelyingPartyRegistration` objects, we default an SP entity ID to
```
{baseUrl}/saml2/service-provider-metadata/{registrationId}
```
`+{baseUrl}/saml2/service-provider-metadata/{registrationId}+`
That means in our two provider configuration, our system would look like
@ -401,12 +397,15 @@ spring:
----
If this is not desirable, you can manually override the local SP entity ID by using the
```
[source,attrs="-attributes"]
----
localEntityIdTemplate = {baseUrl}/saml2/service-provider-metadata
```
----
If we change our local SP entity ID to this value, it is still important that we give
out the correct single sign on URL (the assertion consumer service URL)
for each registered identity provider based on the registration Id.
`{baseUrl}/login/saml2/sso/{registrationId}`
`+{baseUrl}/login/saml2/sso/{registrationId}+`