Expected Behavior

String metadataLocation = "C:\\local\\temp\\saml\\meta.xml";

RelyingPartyRegistration registration = RelyingPartyRegistrations.fromMetadataLocation(metadataLocation)
 .registrationId("registration-id").build();

Current Behavior

String metadataLocation = "https://testAssertingParty.com/meta.xml";

RelyingPartyRegistration registration = RelyingPartyRegistrations.fromMetadataLocation(metadataLocation)
 .registrationId("registration-id")
.build();

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):

public static RelyingPartyRegistration.Builder fromMetadataLocation(String metadataLocation) {
    try {
        if (metadataLocation.matches("^(https?)://.*$")) {
            RestOperations rest = new RestTemplate(Arrays.asList(new OpenSamlRelyingPartyRegistrationBuilderHttpMessageConverter()));
            return rest.getForObject(metadataLocation, RelyingPartyRegistration.Builder.class);
        } else {
            OpenSamlRelyingPartyRegistrationBuilderConverter converter = new OpenSamlRelyingPartyRegistrationBuilderConverter();
            return converter.read(RelyingPartyRegistration.Builder.class, new FileInputStream(metadataLocation));
        }
    }
    catch (RestClientException | FileNotFoundException ex) {
        if (ex.getCause() instanceof Saml2Exception) {
            throw (Saml2Exception) ex.getCause();
        }
        throw new Saml2Exception(ex);
    }
}

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.

Comment From: Koshux

+1

Would greatly appreciate it if this effort could be looked into!

Comment From: jzheaux

Thanks for the suggestion, @ryan13mt.

I think the proposal is a good start. Some things come to mind:

  • We should leave the conversion strategy from InputStream to RelyingPartyRegistration.Builder package-private for now. We can always make it public later if needed.
  • OpenSamlRelyingPartyRegistrationBuilderConverter sounds a little bit vague. I'm wondering if OpenSamlAssertingPartyMetadataConverter is better since that indicates that it's converting metadata from the IdP.
  • ResourceLoader might be better than RestTemplate since it offers classpath-, file-, and URL-based resource retrieval. At that point, RelyingPartyRegistrations could do instead:
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?

Comment From: ryan13mt

@jzheaux I opened a pull request to see if im heading in the right direction with this

Comment From: dawi

When will this feature be available? Could it be part of the next 5.4.2 release?

Comment From: ryan13mt

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

Comment From: jzheaux

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.