How to implement single callback path for signin for a number of dynamic providers

[laki889]

Hi everyone!

In my current project, I'm working with Identity Server 7 and .NET 8, and I'm tasked with implementing Single Sign-On (SSO) with a number of external identity providers. To streamline this process, I'm using the dynamic providers feature, which allows us to add identity providers on the fly.

My goal is to configure a single callback path for all these dynamic external identity providers. Instead of having separate callback paths for each provider, I want them all to share one common path. In technical terms, this means setting a single path prefix for the Oidc options property, regardless of the provider.

Here’s the issue I'm facing: By default, the Duende Identity Server, in case I had three dynamic providers (let’s call them provider1, provider2, and provider3) would require each provider to have their own unique callback path like so:
/federation/provider1/signin
/federation/provider2/signin
/federation/provider3/signin

This setup becomes cumbersome because the external identity provider we’re integrating with requires that all potential callback paths be pre-configured on their end. This means that any new provider added to our system would not work until its callback path has been manually configured in the external provider's system. This manual step defeats the purpose of having a dynamic system.

To solve this, I propose using a unified callback path for all providers, such as "/federation/externalprovider". This approach would mean that any new providers added would immediately be operational without requiring additional configuration, making the system truly dynamic and efficient.
This approach worked with RSK's Dynamic Auth NuGet package (single callback path for all external providers).

Things I already tried in my project (nothing worked for me - the auth process was not successful):

• Overriding the Configure method ("CustomOidcConfigureOptions").
  1. Change the property context.DynamicProviderOptions.PathPrefix to the value of "/federation/externalprovider";
  2. Change the property context.PathPrefix to the value of "/federation/externalprovider";
  3. Change the property oidcOptions.CallbackPath to the value of "/federation/externalprovider"

Any help or advice would be great!
Thanks

[RolandGuijt]

Each provider needs its own callback path because it lets IdentityServer identify the right provider it has to use based on the callback path. It is used to distinguish between schemes since under the covers individual remote authentication handlers (the standard ones by MS) are used. Right now unfortunately there isn't a way to get around this.

This setup becomes cumbersome because the external identity provider we’re integrating with requires that all potential callback paths be pre-configured on their end.

I'm assuming this external identity provider you're talking about is a dynamic provider configured in IdentityServer? Why does it need to know all the other callback paths?

[laki889]

I'm assuming this external identity provider you're talking about is a dynamic provider configured in IdentityServer? Why does it need to know all the other callback paths?

In the project I'm involved with, we are integrating our software with a major enterprise system used in the healthcare sector. The initial phase of this integration involves setting up single sign-on (SSO). This feature allows users to log into our platform using their credentials from what we refer to as the "external app."
The enterprise application we are connecting with is hosted on-premises, meaning that each of its clients has their own dedicated servers. From our application's perspective, each client's installation acts as a distinct external identity provider. Consequently, we are implementing dynamic providers in our application to accommodate this setup.

Why does it need to know all the other callback paths?

The design of enterprise-level apps often prioritizes security, which likely explains the setup process for single sign-on (SSO) systems. To use their services, you must first create an application on their platform. Within this application, you must specify what they refer to as "Return URLs". For example, you would need to add a URL like "https://myapp.com/federation/provider1/signin". Failing to add this URL disrupts the OAuth flow, thus preventing SSO from functioning. This requirement compromises the concept of fully dynamic external identity providers, as each "Return URL" needs to be manually entered to ensure the complete setup functions properly.

Originally, I used the Duende Identity Server and RSK's Dynamic Auth product (available as a NuGet package) for the implementation. RSK's Dynamic Auth allowed for a single callback path that worked with all external providers. However, this RSK product isn't included in the Enterprise Identity Server license, forcing me to adopt Duende's dynamic provider implementation instead.

Do you have any insights on how RSK's implementation works and how they managed to successfully implement this feature? I believe that they are also using the Duende dynamic providers under the hood - I think that their Dynamic Auth is just kind of a wrapper around Duende's dynamic providers feature

[AndersAbel]

Thank your for the explanation. If I understand this right, each external IdentityProvider instance is only connected to one authentication scheme in the IdentityServer. On your end, you have one IdentityServer that interacts with all the different customers.

The way the Duende dynamic providers feature is designed it requires each provider to have their own callback path. The reason is both because of performance and for increased security.

The RSK dynamic providers package is completely separate from the Duende implementation. They are a separate company (although being a Duende partner) and they might have made other design decisions for their implementation.

If you have an existing implementation with their solution that works for you, maybe the easiest is to just continue using that one? If it is compatible with standard Asp.Net Core it should work together with Duende IdentityServer too.

[RolandGuijt]

@laki889 Did Anders' comment clear things up for you? If so I'd like to close.

[laki889]

Thank you for the clarification.

However, I see room for improvement in Duende IdentityServer (IS). Paying for an additional RSK license on top of the Duende Enterprise license seems unreasonable. A key motivation for purchasing the Enterprise Duende license was the dynamic providers feature, and we expect this feature to be genuinely dynamic, similar to the RSK package.