AdminUI is a management tool for IdentityServer that interacts with both the client configuration and user store. AdminUI streamlines client configuration and user management along with additional features such as full auditing, accessibility and importing/exporting your client configurations to your IdentityServer instance out of the box.
By default, IdentityServer4 has support for ASP.NET Core Identity as its user store, which AdminUI extends and builds upon with our IdentityExpress schema. In order to use AdminUI, users must migrate their user store to our IdentityExpress schema.
However, migrating a user store can be a momentous task. And if you aren’t ready to migrate your user store over to our IdentityExpress schema, or if you are using an older schema like ASP.NET Membership and cannot upgrade due to interoperability of older systems, it can be more difficult to take advantage of AdminUI.
Currently, AdminUI only supports our IdentityExpress schema. But it is possible to configure AdminUI to not use the user management functionality and still be able to use the client configuration and other features.
In this article, we will guide you on how you can use AdminUI to only manage your IdentityServer configuration. However, if you are considering moving from the default ASP.NET Core Identity schema, check out our tooling that can migrate you from ASP.Net Identity to the IdentityExpress schema.
Setup
To follow this article, you’ll need a working IdentityServer4 and an AdminUI license key. You can find a sample IdentityServer on our GitHub, and you can get a demo key for AdminUI from IdentityServer.com. We recommend that you download our AdminUI installer, which will install both AdminUI and a demo IdentityServer4 instance, both fully configured and ready to use.
Default Architecture
AdminUI is a client application that manages IdentityServer’s databases but is also secured by IdentityServer. Below is a diagram of a typical AdminUI and IdentityServer setup
AdminUI is acting upon both the user and configuration databases of IdentityServer. While also connecting to IdentityServer in order to authenticate and obtain access tokens.
When AdminUI starts up, it will connect to IdentityServer and its user and configuration databases and check everything is up and running correctly. However, if you are using an older user store, it will fail during the start-up process. So, we want to avoid AdminUI connecting to a user database with a schema it does not recognize.
Custom User Store Architecture
To achieve this, we can create a blank IdentityExpress user database and use its connection string in AdminUI’s configuration. This means that AdminUI will not look at your custom user database, but instead at an empty user database with the correct schema. This allows AdminUI to get through the startup process.
You can use our Migration tool to quickly get up a blank database up and running, and then modify the Identity Connection String value to the connection string of the new blank database using your preferred method (Application Config, IIS/Azure environment variables, appsettings.json file etc).
So, our new setup would look like the following:
With AdminUI connecting to IdentityServer for authentication and the IdentityServer database in order to manage client configuration and our blank Identity Express database.
Granting access to AdminUI
AdminUI uses policy settings to determine access. By default, AdminUI will look for the role claim “AdminUIAdministrator” on the requesting user’s claims and access token.
AdminUI does not communicate with the user store for authorization, so we can use this to give our users access without needing to call the dummy user store. When a user logs onto AdminUI, they will be redirected to their IdentityServer to authenticate, which is still connected to your ASP.NET Membership database. If the authentication is successful, IdentityServer will complete the OpenID Connect authorization process and provide the user’s details to AdminUI. If the user info and access token contain the correct claims as defined in the AdminUI policy page, the user will be granted access.
The exact policy and claims used can be configured in the settings page. You could specify only specific users by adding a policy with the Claim Type “sub”, with the subject of the user you want to be able to access AdminUI. Or, keep with the default and give users the role “AdminUIAdministrator”
AdminUI will not be able to access or manage any of your users but you can still use AdminUI to manage your Clients and Resources, as well as access many other features.
Looking to implement AdminUI to only manage your client configuration? Want some assistance in the setup? Feel free to reach out to support@identityserver.com
