RelyingPartyRegistrations should not fail when SPSSODescriptor elements are present

[stnor]

I am trying to migrate from the old SAML extension project to the new. on Spring 5.8.x (not boot).

It would be good if i could use RelyingPartyRegistrations.collectionFromMetadataLocation() could skip "SP" entries instead of throwing exceptions.

Right now I am getting org.springframework.security.saml2.Saml2Exception: Metadata response is missing the necessary IDPSSODescriptor element

Ideally there should be a flag to skip entities without IDPSSODescriptor. In this federation, there are SPSSODescriptor:s mixed in the same metadata as the IdP:s in this case.

See https://fed.skolfederation.se/prod/md/skolfederation-3_1.xml (A Federation for school owners (IdP) ca 200+ and e-learning resources (SPs) in Sweden).

Since the classes are package private and final, it is hard to work around the issue at present.

The only possible workaround seems to be to copy classes..

Also, how does one parse and store the other metadata, that was read by the old implementation, such as "organisation.name" when RelyingPartyRegistration is final and there are no hooks in the code afaik. Couldn't it be an interface instead? Or expose the XMLObject?

I have a dropdown list to select the IdP by OrgName in my implementation today, that's using the old project.

I'm unable to find a migration guide, and the docs are pretty sparse.

Thanks.

[jzheaux]

Hi, @stnor, thanks for the detailed report.

Looks like there are a couple of things here.

• Address SPSSODescriptor error handling
• Add to SAML Metadata documentation for getting the underlying XMLObject (already supported, undocumented, though)

I've added #12667 to address the second one. As for the first one, yes, I think that makes sense to add and am happy to use this ticket to address that.

I'm unable to find a migration guide

It is in our Wiki: https://github.com/spring-projects/spring-security/wiki/SAML-2.0-Migration-Guide - note that the main page didn't have it in the bullet list, so I've added it there to make it easier to see.

[stnor]

Great, thanks for the prompt response.

I am looking at the migration guide right now, and I am unable to tell if the URL:s are the same form that page. Granted, I can look at the code, but ideally the URL:s should be documented if they are changed.

I am using this configuration at the moment. I can't tell if they're considered "default" or not.

// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/login/**"), samlEntryPoint()),
// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/login/**"), samlLogoutFilter()),
// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/logout/**"), samlEntryPoint()),
// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/SingleLogout/**"), samlLogoutProcessingFilter()),
// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/metadata/**"), samlMetadataDisplayFilter()),
// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/SSO/**"), samlWebSSOProcessingFilter(authenticationManager)),
// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/SSOHoK/**"), samlWebSSOHoKProcessingFilter(authenticationManager)),
// new DefaultSecurityFilterChain(new AntPathRequestMatcher("/saml/discovery/**"), samlIdpDiscovery())

[stnor]

Ah, I found this: https://github.com/spring-projects/spring-security-samples/tree/main/servlet/spring-boot/java/saml2/custom-urls

Will be very useful for migration.

[stnor]

I think I might be asking for the wrong thing here after looking at #10551 ?

@jzheaux To be clear, I want to participate in the Federation mentioned above as an SP and let the user select what IdP to use for authenticating with my service. Shouldn't I have just one RelyingParty, with the SAME callback url for all IdP:s. I can only publish one URL in the federation, and it can't obviously be IdP specific then.

Is this possible with 'new' SAML at present? If so, how to go about it?

[jzheaux]

@stnor, yes this is possible. The key is to reuse the same relying party configuration for each relying party registration instance.

Note that by default, the callback URLs will contain a unique registration id so that Spring Security can lookup the right IdP configuration. If you want to have the exact same callback URL for all IdPs, then you will need to specify how to perform the lookup.

[jzheaux]

Are you able to provide a PR for improving OpenSamlAssertingPartyDetailsConverter as you described?