Description
Saml2WebSsoAuthenticationFilter, Saml2WebSsoAuthenticationRequestFilter, and upcoming filters like Saml2MetadataFilter and any request-based logout support will all need to look up the RelyingPartyRegistration.
Currently, the way that Saml2WebSsoAuthenticationFilter and Saml2WebSsoAuthenticationRequestFilter look up the registration is by using a pattern in the URL path to discover the the registration id and then querying the RelyingPartyRegistrationRepository.
As was noted in a separate ticket, there's value in being able to derive the registration in ways other than by a path placeholder. For example, some may derive it via some other request aspect like the host name. Using other strategies to derive the registration can also simplify IdP configuration by making the IdP only need to know about one set of paths for the SP.
Since this strategy would need to be configured on each filter, it's reasonable to consider a shared strategy like Converter<HttpServletRequest, RelyingPartyRegistration>. The default implementation would discover the registration id by path and look up the RelyingPartyRegistration by that registration id.
An additional benefit to consolidating this functionality is in resolving templates in RelyingPartyRegistration instances. The entityId and assertionConsumerServiceLocation are defined to allow placeholders, and these placeholders can only be resolved using the HttpServletRequest. This means that these values are not as useful at the service layer unless they are first resolved at the web layer. This default resolver, then, could also resolve the templates in the RelyingPartyRegistration so that they can have meaningful values at the service layer.
If added, this would either be valuable as a component of each filter, thereafter passing the RelyingPartyRegistration to the appropriate collaborators, or those collaborators themselves could instead use this component, simplifying their contract.
For example, Saml2AuthenticationRequestContextResolver, currently has a resolve method:
public Saml2AuthenticationRequestContext resolve(
HttpServletRequest request, RelyingPartyRegistration registration)Given this new component, the contract could be simplified to:
public Saml2AuthenticationRequestContext resolve(HttpServletRequest request)and Saml2AuthenticationRequestContextResolver would simply delegate to this new component to retrieve the registration.
One benefit to changing the contract in this way is it makes it easier to consider things like a generic resolver interface since such an interface would likely take only one parameter.