The extendability of IdentityServer

[gislikonrad]

The premise

I'd like to start a discussion around the extendability of IdentityServer. The OpenID spec is growing exponentially. We need a way to extend IdentityServer properly, without using dirty hacks.

The things I'm most interested in are:

• Custom response modes
• Custom response types
• Adding parameter handling to existing endpoint requests
• Adding response properties to existing endpoint responses

Hacks

At my company, we have created two custom response modes. The way we did it was incredibly hacky, using reflection to add to the Constants.AllowedResponseModesForGrantType and Constants.SupportedResponseModes.

public static class IdentityServerConstantsOverride
{
    private static int _applied = 0;

    private static readonly List<string> _responseModes = new List<string>();
    
    public static void AddResponseMode(string mode)
    {
        if (_applied == 1)
        {
            if (ThrowExceptionOnApplied)
                throw new InvalidOperationException("Overrides have already been applied.");
            return;
        }

        if (!_responseModes.Contains(mode))
            _responseModes.Add(mode);
    }

    internal static void Apply()
    {
        // This is added for testing purposes
        if (Interlocked.Exchange(ref _applied, 1) == 1)
        {
            if (ThrowExceptionOnApplied)
                throw new InvalidOperationException("Overrides have already been applied.");
            return;
        }
        var constants = typeof(IIdentityServerBuilder)
                .Assembly
                .GetTypes()
                .Where(t => t.Name == "Constants")
                .OrderBy(t => t.Namespace)
                .FirstOrDefault()
            ;

        if (constants == null) 
            throw new ApplicationException("Unable to change response_mode validation");

        var allowedResponseModesForGrantType = constants
                .GetField("AllowedResponseModesForGrantType", BindingFlags.Public | BindingFlags.Static)
                ?.GetValue(null) as Dictionary<string, IEnumerable<string>>
            ;

        var supportedResponseModes = constants
                .GetField("SupportedResponseModes", BindingFlags.Public | BindingFlags.Static)
                ?.GetValue(null) as List<string>
            ;

        if (allowedResponseModesForGrantType == null || supportedResponseModes == null)
            throw new ApplicationException("Unable to change response_mode validation");
        
        supportedResponseModes.AddRange(_responseModes.Distinct());
        var keys = allowedResponseModesForGrantType.Keys.ToArray();
        foreach (var key in keys)
        {
            var responseModes = allowedResponseModesForGrantType[key];
            allowedResponseModesForGrantType[key] = responseModes.Concat(_responseModes).Distinct().ToArray();
        }
    }

    internal static bool ThrowExceptionOnApplied = true;
}

There is more that we had to do to support the custom response modes, for example override the response generators and shim the response so that it gets through the processing in AuthorizeResult, but this is the main hack. This isn't ideal, feels dirty, and could break in any update to IdentityServer, for example if Duende decided to use constants rather than static values internally.

Discussion

The validity of our custom response modes is not the topic for discussion here, and I'm not going to go into what they are and what we could do instead. What I want to discuss is how a developer would implement OpenID extensions like OpenID4VC, OpenID4VCI, OpenID4VP, Rich Authorization Requests, etc.

These specs use things like custom response types (vp_token), response modes (direct_post and direct_post.jwt), custom request parameters and/or custom response properties. For the most part, the custom request parameters and custom response properties aren't a problem, but for CIBA they are. You would not be able to implement Rich Authorization Requests for CIBA.

@brockallen and @damianh I did discuss this with you guys in Iceland. I hope we can find some common ground for this stuff.

[damianh]

Fantastic write up, thank you for taking the time @gislikonrad !

[RolandGuijt]

@josephdecock

[josephdecock]

Thanks for all these details - it's really helpful to us to see where the extensibility model needs help! Your use case seems very valid and we intend to improve this in a future release.

[msaldaco]

I would also like to see better extendibility on the EF DbContexts if feasible.

I wanted to add a new table called IdentityProviderClaims to assign common claims to all users signing in under a specific provider, and ran into roadblocks when trying to add a navigation property for it to the IdentityProvider model, especially with the migrations. I basically had to register the regular ConfigurationDbContext so the framework worked, and then create a separate DbContext, copy the DbSets and model builder logic, delete the migrations, and recreate them based off the new context.

If something could be done similar to how IdentityDbContext from ASP.NET Identity works, I think it could remain backwards compatible, though it be quite a bit of rewriting.

Maybe, like:

public class ConfigurationDbContext<TContext> : ConfigurationDbContext<TContext, Client, ClientCorsOrigin, IdentityResource, ApiResource, ApiScope, IdentityProvider>
    where TContext : DbContext, IConfigurationDbContext
{

}

public class ConfigurationDbContext<TContext, TClient, TClientCorsOrigin, TIdentityResource, TApiResource, TApiScope, TIdentityProvider> : ConfigurationDbContext<TContext, TClient, TClientCorsOrigin, TIdentityResource, TApiResource, TApiScope, TIdentityProvider, ApiScopeClaim, ApiScopeProperty, ...>
    where TContext : DbContext, IConfigurationDbContext
    where TClient : Client
    where TClientCorsOrigin : ClientCorsOrigin
    where TIdentityResource : IdentityResource
    where TApiResource : ApiResource
    where TApiScope : ApiScope
    where TIdentityProvider : IdentityProvider
{
}

public class ConfigurationDbContext<TContext, TClient, TClientCorsOrigin, TIdentityResource, TApiResource, TApiScope, TIdentityProvider, TApiScopeClaim, TApiScopeProperty, ...> : DbContext, IConfigurationDbContext
    where TContext : DbContext, IConfigurationDbContext
    where TClient : Client
    where TClientCorsOrigin : ClientCorsOrigin
    where TIdentityResource : IdentityResource
    where TApiResource : ApiResource
    where TApiScope : ApiScope
    where TIdentityProvider : IdentityProvider
    where TApiScopeClaim : ApiScopeClaim
    where TApiScopeProperty : ApiScopeProperty
{
    public DbSet<TClient> Clients { get; set; }

    public DbSet<TApiResource> ApiResources { get; set; }

    public DbSet<TIdentityProvider> IdentityProviders { get; set; }
    
    // ...
}

And maybe if someone needed change out the underlying navigation properties:

class ApiScope : ApiScope<ApiScopeClaim, ApiScopeProperty>
{
    // ...
}

class ApiScope<TApiScopeClaim, TApiScopeProperty>
    where TApiScopeClaim : ApiScopeClaim
    where TApiScopeProperty : ApiScopeProperty
{
    public int Id { get; set; }
    public bool Enabled { get; set; } = true;
    public string Name { get; set; }
    // ...
    public List<ApiScopeClaim> UserClaims { get; set; }
    public List<ApiScopeProperty> Properties { get; set; }
    // ...
}

class ExtendedIdentityProvider
{
    public DbSet<IdentityProviderClaim> Claims { get; set; }
}

class ExtendedApiScopeProperty : ApiScopeProperty
{
    public bool Disable { get; set; }
}

class ExtendedApiScope : ApiScope<ApiScopeClaim, ExtendedApiScopeProperty>
{

}

public class ExtendedDbContext : ConfigurationDbContext<ExtendedDbContext, Client, ApiResource, ExtendedIdentityProvider, ExtendedApiScope, ExtendedApiScopeProperty, ApiScopeClaim, ...>
{
    // ...
}

It's definitely a lot, but it makes it easier to keep the core models in line with the framework without having to periodically check the source code and see what changed, then copy and paste.

[maartenba]

Related: https://github.com/orgs/DuendeSoftware/discussions/132

[gislikonrad]

To be fair, I don't agree that this is the same issue. I'm not saying the extensability of the entity framework implementation isn't without its faults, but the original discussion is geared towards new oidc and oauth specs and how difficult it would be to implement them in IdentityServer in the current version.