Generic ConfigurationDbContext And PersistedGrantDbContext

[HarryPooni-Omnio]

IdentityServer version

v7

.NET version

.net 9

Description

Current implementation of DBContext aren't generic and make it difficult to extend with new properties or custom capabilities. Microsoft ApplicationUser has this capability, there should be no reason why Duende can't follow suite.

Reproduction steps

No response

Expected behavior

No response

Logs

No response

Additional context

No response

[maartenba]

Related: https://github.com/orgs/DuendeSoftware/discussions/87#discussioncomment-12543611

[RolandGuijt]

Can you please let us know the specifics on what you're trying to achieve? What kind of properties and custom capabilities?

[HarryPooni-Omnio]

We're implementing a multi-tenancy implementation, where our client config and identity provider needs to be tenant aware when the resource is created and consumed within the Duende platform. I am also writing an API to manage the Identity Providers, Clients as well as Users and roles via the DbContexts. AspIdentity provides a generic implementation for User Management, but we don't have one for either Configuration and persisted store.

In addition the interface associated with the contexts aren't generic either.

Do you have a working example of all the changes required for Multi-Tenancy?

[RolandGuijt]

There is the possibility to derive from the DbContexts to add whatever you want. E.g.:

public class MyConfigurationDbContext : ConfigurationDbContext
{
    public MyConfigurationDbContext(DbContextOptions<ConfigurationDbContext> options) : base(options)
    {
    }
}

Then in the registration, specify that type:

.AddConfigurationStore<MyConfigurationDbContext>(options =>
{
   options.ConfigureDbContext = builder => builder.UseSqlServer(connectionString);
})

Would that be enough for your needs? If not why do you need the contexts to be generic? Can you give an example?

We don't have examples on multi tenancy at the moment because there are so many ways to do it. The specifics vary too much by org.

[HarryPooni-Omnio]

I would like to extend the Client and IdentityProviders without creating a new entity. The IConfigurationDbContext should be generic types too.

[HarryPooni-Omnio]

public interface IConfigurationDbContext
    <TClients, 
    TClientCorsOrigin, 
    TIdentityResource, 
    TApiResource,
    TApiScope,
    TIdentityProvider
    > : IDisposable
where TClients : Client
where TClientCorsOrigin : ClientCorsOrigin
where TIdentityResource : IdentityResource
where TApiResource : ApiResource
where TApiScope : ApiScope
where TIdentityProvider : IdentityProvider
{
    /// <summary>
    /// Gets or sets the clients.
    /// </summary>
    /// <value>
    /// The clients.
    /// </value>
    DbSet<TClients> Clients { get; set; }
        
    /// <summary>
    /// Gets or sets the clients' CORS origins.
    /// </summary>
    /// <value>
    /// The clients CORS origins.
    /// </value>
    DbSet<TClientCorsOrigin> ClientCorsOrigins { get; set; }

    /// <summary>
    /// Gets or sets the identity resources.
    /// </summary>
    /// <value>
    /// The identity resources.
    /// </value>
    DbSet<TIdentityResource> IdentityResources { get; set; }

    /// <summary>
    /// Gets or sets the API resources.
    /// </summary>
    /// <value>
    /// The API resources.
    /// </value>
    DbSet<TApiResource> ApiResources { get; set; }

    /// <summary>
    /// Gets or sets the scopes.
    /// </summary>
    /// <value>
    /// The identity resources.
    /// </value>
    DbSet<TApiScope> ApiScopes { get; set; }

    /// <summary>
    /// Gets or sets the identity providers.
    /// </summary>
    /// <value>
    /// The identity providers.
    /// </value>
    DbSet<TIdentityProvider> IdentityProviders { get; set; }
    
    /// <summary>
    /// Saves the changes.
    /// </summary>
    /// <returns></returns>
    Task<int> SaveChangesAsync(CancellationToken cancellationToken);

    // this is here only because of this: https://github.com/DuendeSoftware/IdentityServer/issues/472
    // and because Microsoft implements the old API explicitly: https://github.com/dotnet/aspnetcore/blob/v6.0.0-rc.2.21480.10/src/Identity/ApiAuthorization.IdentityServer/src/Data/ApiAuthorizationDbContext.cs

    /// <summary>
    /// Saves the changes.
    /// </summary>
    /// <returns></returns>
    Task<int> SaveChangesAsync() => SaveChangesAsync(CancellationToken.None);
}

[HarryPooni-Omnio]

public interface IPersistedGrantDbContext<
    TPersistedGrant,
    TDeviceFlowCodes,
    TKey,
    TServerSideSession,
    TPushedAuthorizationRequest
> : IDisposable
where TPersistedGrant : PersistedGrant
where TDeviceFlowCodes : DeviceFlowCodes
where TKey : Key
where TServerSideSession : ServerSideSession
where TPushedAuthorizationRequest : PushedAuthorizationRequest
{
    /// <summary>
    /// Gets or sets the persisted grants.
    /// </summary>
    /// <value>
    /// The persisted grants.
    /// </value>
    DbSet<TPersistedGrant> PersistedGrants { get; set; }

    /// <summary>
    /// Gets or sets the device flow codes.
    /// </summary>
    /// <value>
    /// The device flow codes.
    /// </value>
    DbSet<TDeviceFlowCodes> DeviceFlowCodes { get; set; }

    /// <summary>
    /// Gets or sets the keys.
    /// </summary>
    /// <value>
    /// The keys.
    /// </value>
    DbSet<TKey> Keys { get; set; }

    /// <summary>
    /// Gets or sets the user sessions.
    /// </summary>
    /// <value>
    /// The server side sessions.
    /// </value>
    DbSet<TServerSideSession> ServerSideSessions { get; set; }

    /// <summary>
    /// Gets or sets the pushed authorization requests.
    /// </summary>
    /// <value>
    /// The pushed authorization requests.
    /// </value>
    DbSet<TPushedAuthorizationRequest> PushedAuthorizationRequests { get; set; }

    /// <summary>
    /// Saves the changes.
    /// </summary>
    /// <returns></returns>
    Task<int> SaveChangesAsync(CancellationToken cancellationToken);

    // this is here only because of this: https://github.com/DuendeSoftware/IdentityServer/issues/472
    // and because Microsoft implements the old API explicitly: https://github.com/dotnet/aspnetcore/blob/v6.0.0-rc.2.21480.10/src/Identity/ApiAuthorization.IdentityServer/src/Data/ApiAuthorizationDbContext.cs

    /// <summary>
    /// Saves the changes.
    /// </summary>
    /// <returns></returns>
    Task<int> SaveChangesAsync() => SaveChangesAsync(CancellationToken.None);
}

[RolandGuijt]

Our Entity Framework implementation could be seen as an example on how to implement the store interfaces in Duende IdentityServer that happens to be sufficient for many scenarios when not too much customization is needed.

There however is the EF customization support which I pointed out in my earlier comment and there's also the possibility to use the generic extension methods that register the contexts that enable you to use your own DbContexts instead of the ones in the package. Using this method however requires you to use the exact scheme the existing DbContexts have but you would be able to add your own properties to the entities.

If even more customization is needed: there's the stores abstraction layer. Instead of looking at the level of the DbContext for customization you can look at the store interfaces which are fairly easy to implement. Please take a look at how they are implemented in the Entity Framework package and you'll see what I mean.
By creating your own store classes and registering them in DI you can use any data store and entity framework with any schema you require.

[HarryPooni-Omnio]

But the properties within the database still need to exists which is where the changes to the dbcontext are necessary. You have many examples of implementations with your templates but extending to accommodate multiple database models is still a challenge for many and put yourselves at a disadvantage against your rivals.

The implementation I have shouldn't break your existing standard implementation, as the entities are your base entities but will provide a your consumers more advanced capabilities when needed.

[damianh]

Hi @HarryPooni-Omnio,

just to give you quick update as we've been discussing this matter internally. I'll share that we're apprehensive of encouraging/facilitating extensibility at this layer. Schema changes for us have been extremely problematic as even the smallest alteration is considered a breaking change. This in turn causes significant friction to users upgrading when doing so also requires a database migration. Over the years we've had to put on hold several things just because they impacted storage thus only being able to accommodate with a new major version. Thus, we fear that extending here will cause you friction and issues with future upgrades.

With that, we're considering our storage architecture and extensibility approaches for the next major version. Our desired approach to extensibility would be first class concern in our APIs and not at EF/DBContext level. Indeed we are considering the possibility of being more 'document' orientated in places. In preparation for designing this, we'd like to gather extensibility use cases so please share 🙏🏻

• Damian

Tagging @msaldaco.