Integrating Thinktecture IdentityServer database with an existing database

This is post 3 in a short 3 part series on describing the database support in v2 of Thinktecture.IdentityServer. The parts of this series are:

1. Database support in Thinktecture IdentityServer.
2. EF migrations in Thinktecture IdentityServer.
3. Integrating Thinktecture IdentityServer database with an existing database (this post).

With the default configuration, the database that contains the configuration information for IdentityServer is its own separate database. It’s understandable that you might want that configuration database to be merged with an existing database. This post provides an approach to solving this requirement.

If you are not using EF code first already for the existing database, then there’s little to do other than to create the schema needed for IdentityServer. This can be done with the migrations discussed in the last post. But if you are using an existing DbContext class and want to merge the IdentityServer schema into the same database then you will run into the “The model backing the ‘IdentityServerConfigurationContext’ context has changed since the database was created. Consider using Code First Migrations to update the database” error. The problem is that the two different DbContext classes want to “own” the schema and so the solution is to merge them.

To get started in understanding the solution, it’s helpful to inspect the code that revolves around the IdentityServer DbContext class, which is IdentityServerConfigurationContext. If you open the solution and locate the “Repositories” project and then open IdentityServerConfigurationContext.cs you will see the class. This is the gist of it:

public class IdentityServerConfigurationContext : DbContext
{
    public DbSet<GlobalConfiguration> GlobalConfiguration { get; set; }
    public DbSet<WSFederationConfiguration> WSFederation { get; set; }
    public DbSet<KeyMaterialConfiguration> Keys { get; set; }
    public DbSet<WSTrustConfiguration> WSTrust { get; set; }
    public DbSet<FederationMetadataConfiguration> FederationMetadata { get; set; }
    public DbSet<OAuth2Configuration> OAuth2 { get; set; }
    public DbSet<SimpleHttpConfiguration> SimpleHttp { get; set; }
    public DbSet<DiagnosticsConfiguration> Diagnostics { get; set; }

    public DbSet<ClientCertificates> ClientCertificates { get; set; }
    public DbSet<Delegation> Delegation { get; set; }
    public DbSet<RelyingParties> RelyingParties { get; set; }
    public DbSet<IdentityProvider> IdentityProviders { get; set; }
    public DbSet<Client> Clients { get; set; }

    public static Func<IdentityServerConfigurationContext> FactoryMethod { get; set; }

    public IdentityServerConfigurationContext()
        : base("name=IdentityServerConfiguration")
    { }

    public static IdentityServerConfigurationContext Get()
    {
        if (FactoryMethod != null) return FactoryMethod();

        return new IdentityServerConfigurationContext();
    }
}

So there are some 13 tables that contain various configuration information. The rest of IdentityServer then uses the repository pattern on these tables to provides access to the rest of the engine. The repositories locate the IdentityServerConfigurationContext via the Get method from the code snippet above.

Given the number of tables and static dependency on this class from within IdentityServer and its Get method, there are two approaches that come to mind to integrate IdentityServer’s DbContext with another DbContext class:

1. Merge the other DbContext‘s tables into IdentityServer’s DbContext, or
2. Extend IdentityServer’s DbContext class and put the new tables into the derived class

For the first suggestion this would entail using IdentityServerConfigurationContext as your primary DbContext and then the rest of your other code would use whatever approach desired to instantiate IdentityServerConfigurationContext for use at runtime. This approach means changing the code in IdentityServer and thus is brittle when there are future updates.

The second suggestion requires no code changes to IdentityServer and thus is the most adaptive when new changes are released. The trick with this approach is that IdentityServerConfigurationContext provides a factory API to create the context (notice the FactoryMethod property above). I’ll illustrate how to implement this approach.

The first step is to create a new context that inherits IdentityServerConfigurationContext and inside define any additional tables needed:

public class CustomContext : IdentityServerConfigurationContext
{
    public DbSet<SomeEntityClass> SomeTable { get; set; }
}

Next in global.asax we need to register the custom context with IdentityServer’s factory delegate and change the database initializer for the custom context:

protected void Application_Start()
{
    IdentityServerConfigurationContext.FactoryMethod = delegate()
    {
        return new CustomContext();
    };

    Database.SetInitializer<CustomContext>(new ConfigurationDatabaseInitializer());
    // this was the old one, so we can comment it our (or remove it)
    //Database.SetInitializer(new ConfigurationDatabaseInitializer());

   ...
}

And that’s it. Anytime IdentityServer needs an IdentityServerConfigurationContext it will be using your derived implementation with its additional tables.

HTH