Migrations

Migrations in the OpenIddict version of AdminUI are optional so these step that follow are not required to get AdminUI working on an existing OpenIddict product. However not all AdminUI features will be available to you such as access policy and claim type configuration in AdminUI, and Audit logging.

To enable claim type configuration through AdminUI you will need to migrate you ASP.Net Identity for AdminUI.

To enable access policy configuration through AdminUI you will need to look at the AdminUI migration section. The specific migration that enables this feature is the ExtendedConfiguration migration.

Migrating ASP.NET Identity Core to AdminUI

If you have an existing ASP.NET Identity Core setup then you will need to run script based migrations on their respective databases before being able to apply the AdminUI migrations. The scripts are only available for SqlServer and would need to be modified to run for PostgreSql or MySql.

Before running the migrations scripts you will need to backup your database as there is no rollback script available from this point.

To migrate your ASP.NET Identity Core schema to then be able to run further migrations you can use the script found here: Migration script.

This requires you to have all AspNetUserClaims records to have a ClaimType value and will add columns and tables to your database. Once the script has finished running you can apply the Identity migration from the AdminUI Migrations section.

AdminUI Migrations

AdminUI comes with a functionality to run all the necessary migrations. If you own SAML2P, and wish to use its respective features within AdminUI, you will need to run the SAML migrations. You can choose which migrations you want to run from settings. Here is an example:

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddAdminUI(
        options =>
        {
            options.MigrationOptions = OpenIddictMigrationOptions.All;
            ...
        }
    );

AdminUI has a number of different migrations that need to be run, you can run one individually or choose to run them all at once.

The different migrations options are:

Migration Type	Description
All	Runs all the migrations (Recommended for Demo users)
AdminUI	Runs only AdminUI migrations (Migrations: ExtendedConfiguration, Audit, Saml and DataProtection)
IdentityOnly	Runs AdminUI migrations along with the Identity migrations (Migrations: Identity, ExtendedConfiguration, Audit, Saml and DataProtection)
OpenIddictOnly	Runs AdminUI migrations along with the OpenIddict migrations (Migrations: Identity, ExtendedConfiguration, Audit, Saml and DataProtection)
ExtendedConfiguration	AdminUI OpenIddict extension
Identity	IdentityExpress Migration (extended version of ASP Identity)
Audit	RSK AdminUI Audit Migration (needs AuditRecordsConnectionString set, by default isn't configured)
Saml	SAML2P Component migration
DataProtection	DataProtection Key Migration (used if protecting cookies with a Database)

Running Migrations with a Custom Database Schema

AdminUI supports running migrations with a custom database schema. The schema configuration must be set at the database level rather than in the application configuration.

Setup Steps

To configure a custom schema:

1. Create the database and custom schema

Create your database and define the custom schema within it.

PostgreSql

1. Add the custom schema to your connections string using Search Path

   Example: "Server=localhost; Port=5433; Uid=MyUserName;Pwd=Password123!;Database=MyDatabase;Search Path=MyCustomSchema;"

SqlServer

1. Configure a database user

Create a database user and assign the custom schema as the user's default schema.

1. Update your connection string

Use the configured user in your AdminUI database connection string.

When using SQL Server, be aware of the following limitation:

• Users with sysadmin role cannot use custom default schemas

If your database user is assigned the sysadmin fixed server role, SQL Server will ignore the default schema setting and always use dbo. This is a SQL Server limitation, not an AdminUI restriction.

To use a custom schema, ensure your database user does not have the sysadmin role. Instead, grant only the specific permissions required for running migrations and operating AdminUI.

For more information, see Microsoft's ALTER USER documentation.