Expected Behavior
SAML IDP registration can be configured via either IDP metadata URL or file-based metadata instead of manually adding configuration property like entity-id, sso-url, X.509 Certificate, etc.. Benefit would be simpler IDP registration configuration and also it can support dynamic configuration like certificate rotation, etc..
spring:
security:
saml2:
relyingparty:
registration:
idpone:
identityprovider:
metadata-url:
idptwo:
identityprovider:
metadata-url:
Current Behavior
Currently spring-security-saml2-service-provider does not support dynamic configuration for IDP using metadata URL. The IDP configuration needs to be added through RelyingPartyRegistration with the different properties like entity-id, sso-url, etc.. Whereas this configuration can be replaced with a single IDP metadata URL which contains all information related to IDP. Also, as an additional option, please allow the same to be configured via file-based metadata.
spring:
security:
saml2:
relyingparty:
registration:
idpone:
identityprovider:
entity-id:
sso-url:
verification:
credentials:
- certificate-location:
idptwo:
identityprovider:
entity-id:
sso-url:
verification:
credentials:
- certificate-location:
Context
My current IDP provides IDP configuration information via metadata URL but due to lack of support in spring-security-saml2-service-provider, we have to manually configure each individual property. As a current alternative, we have option to switch back to old way of configuring SAML IDP using Spring Security SAML Extension(https://docs.spring.io/autorepo/docs/spring-security-saml/1.0.x-SNAPSHOT/reference/htmlsingle/#quick-start-idp-metadata)
Comment From: rwinch
Thanks for creating a ticket. Would you be interested in submitting a Pull Request?
Comment From: imravichaudhary
@rwinch Sure I can definitely take a look whenever I get a chance. Though I haven't contributed to any open source projects so might have to read up Contribution guidelines for the project.
Comment From: rwinch
Thanks @imravichaudhary! The issue is yours. Let us know if you have any questions
Comment From: jzheaux
@imravichaudhary is this something that you are still planning on contributing? I believe @jkubrynski may also be interested.
Comment From: imravichaudhary
@jzheaux @jkubrynski please feel free to contribute.
Comment From: ryan13mt
@jzheaux this only handles URL-based metadata locations right? Can it be changed to handle file-based locations as well?
Comment From: jzheaux
Correct, @ryan13mt, the initial implementation only supports URLs.
File-based support seems like it a possibility. Would you be able to file a separate ticket describing how you'd like something like that to behave so we can explore that in more depth?