Dynamic Providers - Make it easier to add custom IdentityProvider

[maartenba]

Dynamic Providers are quite extensible already, but some things could be made a little bit easier:

1 - The IdentityProvider class has no parameterless constructor, which makes a custom ICache<> for identity providers harder to implement. For example when using JSON to deserialize, this always needs a custom deserializer for the type.

2 - When registering a dynamic provider that is not the default OidcProvider, it is not straightforward to register a custom IdentityProvider class.

As an example, when you register a GoogleIdentityProvider, this would typically look like the following:

// Provider
public class GoogleIdentityProvider : IdentityProvider
{
    // ... ClientId, ClientSecret, ... properties
}

// Registration in IdentityServerOptions
// ...
options.DynamicProviders
    .AddProviderType<GoogleHandler, GoogleOptions, GoogleIdentityProvider>("google");
// ...

// Make sure the GoogleIdentityProvider is mapped to the GoogleHandler's config
services.ConfigureOptions<GoogleDynamicConfigureOptions>();

class GoogleDynamicConfigureOptions
    : ConfigureAuthenticationOptions<GoogleOptions, GoogleIdentityProvider>
{
    protected override void Configure(ConfigureAuthenticationContext<GoogleOptions, GoogleIdentityProvider> context)
    {
        // ...
    }
}

When challenging the "google" scheme, you will see GoogleDynamicConfigureOptions.Configure is never invoked and the handler will throw because no GoogleOptions are configured.

The reason for this is in the default EF Core-backed IdentityProviderStore, the MapIdp() method currently returns null for providers other than OidcProvider (see code here).

A solution is to override IdentityProviderStore and implement MapIdp() to support all dynamic provider types in the solution. This works, but is not straightforward.

A suggestion would be to have MapIdp() work with injected IIdentityProviderMapper instances or similar, where custom IdentityProvider types can be mapped by registering a mapper for them.

[AndersAbel]

The current design invites to replacing the built in EF-backed IdentityProviderStore with a derived version that overrides MapIdp() with a new version that both supports "oidc" and the custom scheme one is working on. This becomes problematic once two or more provider types are added, so the suggestion above to use a set of injected IIdentityProviderMapper instances would be great, as that would allow e.g. a Saml2 provider to register its adapter without conflicting with other protocols.