Saml Callback Path

[KhandelwalMayur28]

I am upgrading my application from Duende IdentityServer 7 (using Sustainsys.Saml2 for SAML integration via the dynamic providers extension point) to Duende IdentityServer 8, and migrating to the new built-in AddSamlDynamicProvider() SAML support.

Our existing SAML SP clients already have callback URLs configured against our old paths:

• federation/{scheme}/ACS
• federation/{scheme}/login

Issue: With AddSamlDynamicProvider(), the docs state the module path is fixed to ~/federation/{scheme}/Saml2, so our ACS endpoint becomes federation/{scheme}/Saml2/ACS. The only configurable piece is DynamicProviderOptions.PathPrefix, which only changes the federation segment, not Saml2.

This is a breaking change for any existing SAML SP integration that has already registered a callback/ACS URL with us, whether they were on the old Duende 7 + Sustainsys pattern or any other prior convention.

Question: Is there any supported way (config option, IConfigureNamedOptions override, or otherwise) to control or remove the Saml2 segment from the dynamic SAML provider callback path, so we can preserve backward compatibility with already-configured client callback URLs during migration? If not currently supported, could this be considered as a configuration option, given it will affect anyone upgrading with existing SAML integrations?

[wcabus]

At this moment, there is no option available to change the underlying ModulePath which resolves to /federation/{scheme}/Saml2 in a dynamic provider context. I'll pass on this question to the engineering team to check if we can change this behavior or to provide an option to configure the module path to become the scheme name instead for dynamic providers.

If you only need a single SAML SP, consider adding it statically instead of dynamically for the time being. Our static SP implementation does allow changing the ModulePath, which you can set to the old path:

builder.Services.AddAuthentication()
    .AddSamlServiceProvider("{scheme}", options =>
    {
        options.SpEntityId = "https://my-app.example.com";
        options.IdpEntityId = "https://corporate-idp.example.com";
        options.SingleSignOnServiceUrl = "https://corporate-idp.example.com/saml2/sso";
        options.SigningCertificatesBase64 = ["<base64-encoded signing certificate>"];
       
        options.ModulePath = "/federation/{scheme}"; // This defaults to "/Saml2"
    });

This should work, unless the {scheme} is also registered as a dynamic provider: you can't have the same scheme twice.

[KhandelwalMayur28]

Thanks for the clarification.

In our case, we are using the dynamic provider approach, as we need to support multiple SAML Service Providers (SPs) across different tenants. Because of this multi-tenant setup, we cannot switch to registering the SPs statically as suggested.

Could you please check with the engineering team whether there is a way to configure or override the ModulePath for dynamic providers, ideally allowing it to use the scheme name (or another tenant-specific value) in the path?

Thanks for looking into this.

[maartenba]

Hi @KhandelwalMayur28 - this is indeed not possible right now for dynamically registered providers. We're looking into what we can do in future versions, but right now the only option is to use a statically configured provider.