Skip to content

Allow RelyingPartyRegistration to be Deduced from Contents of SAML Assertion instead of Path #10243

Closed
@vince-recupito

Description

@vince-recupito

SAML Service Provider should use the contents of a SAML assertion to deduce the IDP instead of the current Path-based defaults when receiving an assertion. This will enable all IDPs to use a shared, common Service Provider configuration.

Currently, the default implementation provides each IDP a separate AssertionConsumerService url to call the Service Provider ("{baseUrl}/login/saml2/sso/{registrationId}"). As an example, with two IDPs registered, we could have the two urls:
{baseUrl}/login/saml2/sso/idp1
{baseUrl}/login/saml2/sso/idp2
Each IDP gets it's own Service Provider metadata that is specific to their IDP.

Instead, an optional implementation should be to have a static AssertionConsumerService url that all IDPs use, and use the entityId within the SAML assertion to choose the correct IDP to validate against. With the same two IDPs above, we would only have:
{baseUrl}/login/saml2/sso

To enable this approach we could have:
An "AssertionRelyingPartyRegistrationResolver" (in addition to the current, DefaultRelyingPartyRegistrationResolver) that would use the contents of the assertion (entityId) to resolve the correct relying party instead of the path-based route

Some work has already been done on this front to enable different RelyingPartyRegistrationResolvers with the following completed issues:
#8887
#8768

Why is this needed?

  • This is the biggest pain point I see from migrating from Spring-Saml-Extension as that library had static service provider metadata for all IDPs. This style should be replicated to the new library to allow ease of migration.
  • It is not feasible in production to have different service provider endpoints per IDP at scale. Our company has currently over 100 different IDPs integrating with our service provider using the old library. Having to distribute individual metadata files to each IDP is more work than having a single service provider metadata with common endpoints that all IDPs can use.
  • Similarly, SAML federations expect a single Service Provider that can be published to all members of the federation. As an example, we belong to https://incommon.org/federation/. If we have to expose different Service Provider metadata for each IDP, it would be impossible to use these federations.
  • This is opinion, but I don't think it is in the spirit of SAML to expose different Service Provider configurations per IDP.

I'm new to this library so there might be more to this ticket than what I wrote. In general, we should be able to distribute the same Service Provider metadata (with the same endpoints) to all IDPs. The most obvious violation of this I saw was the AssertionConsumerService url, but perhaps there are more endpoints/values in the metadata that need to be changed in order to support this (Audience Restriction, Recipient Url, etc)?

Also wanted to say thank you for keeping SAML alive in Spring Security Core as the old project is dead!

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions