-
Notifications
You must be signed in to change notification settings - Fork 6k
File-based Configuration for Asserting Party Metadata #9028
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
+1 Would greatly appreciate it if this effort could be looked into! |
Thanks for the suggestion, @ryan13mt. I think the proposal is a good start. Some things come to mind:
try (InputStream source = resourceLoader.getResource(metadataLocation).getInputStream()) {
return assertingPartyMetadataConverter.convert(source);
} ... Do those changes make sense and would you be able to submit a PR to add this feature? |
@jzheaux I opened a pull request to see if im heading in the right direction with this |
When will this feature be available? Could it be part of the next 5.4.2 release? |
I believe it will be in the 5.5.0 release |
Hi, @dawi, thanks for your interest. Spring Security follows semantic versioning, so only bug fixes will go into 5.4.2. As @ryan13mt said, it will be available in 5.5.0-M1. |
Expected Behavior
Current Behavior
Context
Currently the
RelyingPartyRegistrations.fromMetadataLocation(metadataLocation)
only accepts a URL. Basing on my old implementation with Spring Security SAML Extension it would be good if we could also provide a local directory path to this method. Some asserting parties will not host their metadata files but will instead email it to the relying party.Suggested Solution
The OpenSamlRelyingPartyRegistrationBuilderHttpMessageConverter class introduced in 5.4 can still be used but the parsing logic should be extracted into a separate utility class that can be used elsewhere.
An example of the changes needed in
RelyingPartyRegistrations.fromMetadataLocation(metadataLocation)
:This way if the metadataLocation is a url, it will use the OpenSamlRelyingPartyRegistrationBuilderHttpMessageConverter, if not, it will use the Utility class that holds the parsing code which in my example is named OpenSamlRelyingPartyRegistrationBuilderConverter.
Obviously my code can be greatly improved upon but this change should be an easy one since most of the logic and tests regarding the parsing is already there.
The text was updated successfully, but these errors were encountered: