Rob Winch
parent
5bdf57d1e5
commit
2909d46060
|
|
@ -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
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[[samples]]
|
||||
= Samples
|
||||
|
||||
Spring Security includes many {gh-samples-url}[samples] applications.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>>.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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[]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>>.
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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")
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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}+`
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue