@ -292,11 +291,6 @@ public final class Saml2LoginConfigurer<B extends HttpSecurityBuilder<B>>
@@ -292,11 +291,6 @@ public final class Saml2LoginConfigurer<B extends HttpSecurityBuilder<B>>
@ -339,7 +333,7 @@ public final class Saml2LoginConfigurer<B extends HttpSecurityBuilder<B>>
@@ -339,7 +333,7 @@ public final class Saml2LoginConfigurer<B extends HttpSecurityBuilder<B>>
@ -352,10 +346,14 @@ public final class Saml2LoginConfigurer<B extends HttpSecurityBuilder<B>>
@@ -352,10 +346,14 @@ public final class Saml2LoginConfigurer<B extends HttpSecurityBuilder<B>>
@ -216,17 +215,12 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@@ -216,17 +215,12 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@ -242,18 +236,21 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@@ -242,18 +236,21 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@ -261,7 +258,7 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@@ -261,7 +258,7 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@ -290,15 +287,15 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@@ -290,15 +287,15 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@ -385,12 +382,11 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@@ -385,12 +382,11 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@ -454,10 +450,9 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@@ -454,10 +450,9 @@ public final class Saml2LogoutConfigurer<H extends HttpSecurityBuilder<H>>
@ -666,9 +666,9 @@ In a deployed application, that translates to:
@@ -666,9 +666,9 @@ In a deployed application, that translates to:
The prevailing URI patterns are as follows:
* `+/saml2/authenticate/{registrationId}+` - The endpoint that xref:servlet/saml2/login/authentication-requests.adoc[generates a `<saml2:AuthnRequest>`] based on the configurations for that `RelyingPartyRegistration` and sends it to the asserting party
* `+/saml2/login/sso/{registrationId}+` - The endpoint that xref:servlet/saml2/login/authentication.adoc[authenticates an asserting party's `<saml2:Response>`] based on the configurations for that `RelyingPartyRegistration`
* `+/saml2/logout/sso+` - The endpoint that xref:servlet/saml2/logout.adoc[processes `<saml2:LogoutRequest>` and `<saml2:LogoutResponse>` payloads]; the `RelyingPartyRegistration` is looked up from previously authenticated state
* `+/saml2/saml2-service-provider/metadata/{registrationId}+` - The xref:servlet/saml2/metadata.adoc[relying party metadata] for that `RelyingPartyRegistration`
* `+/login/saml2/sso/+` - The endpoint that xref:servlet/saml2/login/authentication.adoc[authenticates an asserting party's `<saml2:Response>`]; the `RelyingPartyRegistration` is looked up from previously authenticated state or the response's issuer if needed; also supports `+/login/saml2/sso/{registrationId}+`
* `+/logout/saml2/sso+` - The endpoint that xref:servlet/saml2/logout.adoc[processes `<saml2:LogoutRequest>` and `<saml2:LogoutResponse>` payloads]; the `RelyingPartyRegistration` is looked up from previously authenticated state or the request's issuer if needed; also supports `+/logout/saml2/slo/{registrationId}+`
* `+/saml2/metadata+` - The xref:servlet/saml2/metadata.adoc[relying party metadata] for the set of `RelyingPartyRegistration`s; also supports `+/saml2/metadata/{registrationId}+` or `+/saml2/service-provider-metadata/{registrationId}+` for a specific `RelyingPartyRegistration`
Since the `registrationId` is the primary identifier for a `RelyingPartyRegistration`, it is needed in the URL for unauthenticated scenarios.
If you wish to remove the `registrationId` from the URL for any reason, you can <<servlet-saml2login-rpr-relyingpartyregistrationresolver,specify a `RelyingPartyRegistrationResolver`>> to tell Spring Security how to look up the `registrationId`.
@ -849,122 +849,18 @@ open fun relyingPartyRegistrations(): RelyingPartyRegistrationRepository? {
@@ -849,122 +849,18 @@ open fun relyingPartyRegistrations(): RelyingPartyRegistrationRepository? {
As seen so far, Spring Security resolves the `RelyingPartyRegistration` by looking for the registration id in the URI path.
There are a number of reasons you may want to customize that. Among them:
Depending on the use case, a number of other strategies are also employed to derive one.
For example:
* You may already <<relyingpartyregistrationresolver-single, know which `RelyingPartyRegistration` you need>>
* You may be <<relyingpartyregistrationresolver-entityid, federating many asserting parties>>
* For processing `<saml2:Response>`s, the `RelyingPartyRegistration` is looked up from the associated `<saml2:AuthRequest>` or from the `<saml2:Response#Issuer>` element
* For processing `<saml2:LogoutRequest>`s, the `RelyingPartyRegistration` is looked up from the currently logged in user or from the `<saml2:LogoutRequest#Issuer>` element
* For publishing metadata, the `RelyingPartyRegistration`s are looked up from any repository that also implements `Iterable<RelyingPartyRegistration>`
To customize the way that a `RelyingPartyRegistration` is resolved, you can configure a custom `RelyingPartyRegistrationResolver`.
The default looks up the registration id from the URI's last path element and looks it up in your `RelyingPartyRegistrationRepository`.
When this needs adjustment, you can turn to the specific components for each of these endpoints targeted at customizing this:
[NOTE]
Remember that if you have any placeholders in your `RelyingPartyRegistration`, your resolver implementation should resolve them.
[[relyingpartyregistrationresolver-single]]
==== Resolving to a Single Consistent `RelyingPartyRegistration`
You can provide a resolver that, for example, always returns the same `RelyingPartyRegistration`:
====
.Java
[source,java,role="primary"]
----
public class SingleRelyingPartyRegistrationResolver implements RelyingPartyRegistrationResolver {
private final RelyingPartyRegistrationResolver delegate;
public SingleRelyingPartyRegistrationResolver(RelyingPartyRegistrationRepository registrations) {
this.delegate = new DefaultRelyingPartyRegistrationResolver(registrations);
}
@Override
public RelyingPartyRegistration resolve(HttpServletRequest request, String registrationId) {
return this.delegate.resolve(request, "single");
}
}
----
.Kotlin
[source,kotlin,role="secondary"]
----
class SingleRelyingPartyRegistrationResolver(delegate: RelyingPartyRegistrationResolver) : RelyingPartyRegistrationResolver {
override fun resolve(request: HttpServletRequest?, registrationId: String?): RelyingPartyRegistration? {
return this.delegate.resolve(request, "single")
}
}
----
====
[TIP]
You might next take a look at how to use this resolver to customize xref:servlet/saml2/metadata.adoc#servlet-saml2login-metadata[`<saml2:SPSSODescriptor>` metadata production].
[[relyingpartyregistrationresolver-entityid]]
==== Resolving Based on the `<saml2:Response#Issuer>`
When you have one relying party that can accept assertions from multiple asserting parties, you will have as many ``RelyingPartyRegistration``s as asserting parties, with the <<servlet-saml2login-rpr-duplicated, relying party information duplicated across each instance>>.
This carries the implication that the assertion consumer service endpoint will be different for each asserting party, which may not be desirable.
You can instead resolve the `registrationId` via the `Issuer`.
A custom implementation of `RelyingPartyRegistrationResolver` that does this may look like:
====
.Java
[source,java,role="primary"]
----
public class SamlResponseIssuerRelyingPartyRegistrationResolver implements RelyingPartyRegistrationResolver {
private final InMemoryRelyingPartyRegistrationRepository registrations;
You might next take a look at how to use this resolver to customize xref:servlet/saml2/login/authentication.adoc#relyingpartyregistrationresolver-apply[`<saml2:Response>` authentication].
* For SAML Responses, customize the `AuthenticationConverter`
* For Logout Requests, customize the `Saml2LogoutRequestValidatorParametersResolver`
* For Metadata, customize the `Saml2MetadataResponseResolver`
[[federating-saml2-login]]
=== Federating Login
@ -996,6 +892,7 @@ var registrations: Collection<RelyingPartyRegistration> = RelyingPartyRegistrati
@@ -996,6 +892,7 @@ var registrations: Collection<RelyingPartyRegistration> = RelyingPartyRegistrati
@ -1006,15 +903,7 @@ Note that because the registration id is set to a random value, this will change
@@ -1006,15 +903,7 @@ Note that because the registration id is set to a random value, this will change
There are several ways to address this; let's focus on a way that suits the specific use case of federation.
In many federation cases, all the asserting parties share service provider configuration.
Given that Spring Security will by default include the `registrationId` in all many of its SAML 2.0 URIs, the next step is often to change these URIs to exclude the `registrationId`.
There are two main URIs you will want to change along those lines:
* <<relyingpartyregistrationresolver-entityid,Resolve by `<saml2:Response#Issuer>`>>
* <<relyingpartyregistrationresolver-single,Resolve with a default `RelyingPartyRegistration`>>
[NOTE]
Optionally, you may also want to change the Authentication Request location, but since this is a URI internal to the app and not published to asserting parties, the benefit is often minimal.
Given that Spring Security will by default include the `registrationId` in the service provider metadata, another step is to change corresponding URIs to exclude the `registrationId`, which you can see has already been done in the above sample where the `entityId` and `assertionConsumerServiceLocation` are configured with a static endpoint.
You can see a completed example of this in {gh-samples-url}/servlet/spring-boot/java/saml2/saml-extension-federation[our `saml-extension-federation` sample].
@ -46,6 +47,20 @@ public final class OpenSaml4AuthenticationRequestResolver implements Saml2Authen
@@ -46,6 +47,20 @@ public final class OpenSaml4AuthenticationRequestResolver implements Saml2Authen
@ -52,13 +54,14 @@ public class OpenSamlAuthenticationRequestResolverTests {
@@ -52,13 +54,14 @@ public class OpenSamlAuthenticationRequestResolverTests {
@ -76,13 +79,14 @@ public class OpenSamlAuthenticationRequestResolverTests {
@@ -76,13 +79,14 @@ public class OpenSamlAuthenticationRequestResolverTests {
@ -114,13 +118,14 @@ public class OpenSamlAuthenticationRequestResolverTests {
@@ -114,13 +118,14 @@ public class OpenSamlAuthenticationRequestResolverTests {
@ -137,13 +142,14 @@ public class OpenSamlAuthenticationRequestResolverTests {
@@ -137,13 +142,14 @@ public class OpenSamlAuthenticationRequestResolverTests {