Expected Behavior
In DefaultRelyingPartyRegistrationResolver class, there is a private static method resolve() method that is used to resolve URL strings defined in the relying party registration information containing variables, such as {baseHost}, {baseUrl}, etc.
We can enhance this ability by letting the user provide their own HashMap<String> data that can be passed to the UriComponentsBuilder and resolve custom URL template variables the end users use.
https://github.com/spring-projects/spring-security/blob/f82e15d5b65734c64856ec955e82f689bf18fe1f/saml2/saml2-service-provider/src/main/java/org/springframework/security/saml2/provider/service/web/DefaultRelyingPartyRegistrationResolver.java#L87
Current Behavior
In DefaultRelyingPartyRegistrationResolver class, this private static method resolve() method uses the default URL template variables available in the RelyingPartyRegistrationPlaceholderResolvers class. However, if the user needs to do something else with it and provide a different URL component each time, they need to modify the file many times during the ongoing development process.
https://github.com/spring-projects/spring-security/blob/f82e15d5b65734c64856ec955e82f689bf18fe1f/saml2/saml2-service-provider/src/main/java/org/springframework/security/saml2/provider/service/web/RelyingPartyRegistrationPlaceholderResolvers.java#L84
Context
We have a use case where we are helping customers troubleshoot their single sign-on configurations. Due to the nature where we need to offload incoming traffic to our load balancers on multiple domain hosts, we have to go through a whole lot of configurations which could be easily swapped out with the availability to provide our own custom URL template variables in this class.
This includes issues where the web applications are hosted in different context paths on the instances. There is currently no real way to include different context paths in the {baseUrl} templates.
If we can expose a setter method that lets the users set their own custom map of URL template variables for use, that would be great!
Comment From: jzheaux
Thanks for the idea, @tommai78101. I'm not clear yet on how this is better than specifying these values in the RelyingPartyRegistration instance itself. For example, if you have an ACS that looks like this:
spring.security.saml2.relyingparty.registration.adfs.acs-location="{baseUrl}/ACS.saml2"
and you are wanting to swap out the value of {baseUrl} for something else, could you instead do:
spring.security.saml2.relyingparty.registration.adfs.acs-location="the-value-I-need-it-to-be/ACS.saml2"
The reason I ask is that the placeholders are not designed to have their interpolation be customizable. Instead, these should be thought of as keywords that you can use when they suit you. Otherwise, you should set the registration values based on each client's configuration needs.
Does it sound like there is something that I've missed or does the above solution meet your needs?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
Comment From: tommai78101
The reason I ask is that the placeholders are not designed to have their interpolation be customizable. Instead, these should be thought of as keywords that you can use when they suit you. Otherwise, you should set the registration values based on each client's configuration needs.
Does it sound like there is something that I've missed or does the above solution meet your needs?
It met my needs. Thanks.