This article discusses Authentication and Authorization with Identity Server 4: the standard, out-of-box, user-management solution with Identity Server 4 and ASP.NET Core Identity, as well as the main topic: configuring Identity Server 4 to work with a custom users database—which might be the case for many organizations.
1. Identity Server 4
Most modern applications involve mobile and/or web client(s) and a services layer (APIs), across several layers (front end, middle tier and back end). All these layers have to protect resources and implement authentication and authorization against one or more user stores. A typical approach to achieve this is by implementing Identity Server.
Identity Server is an OpenID Connect provider. It implements the OpenID Connect and OAuth 2.0 protocol.
Identity Server has several jobs and features, including:
- protecting your resources
- authenticating users using a local account store or via an external identity provider
- providing session management and single sign-on
- managing and authenticating clients
- issuing identity and access tokens to clients
- validating tokens
These interactions are depicted in the image below:
How IDS4 accomplishes all these functions is a larger subject. Here we are addressing the resources, specifically the identity data of the users.
2. Users Management with IDS4 and ASP.NET Core Identity
IdentityServer is designed for flexibility and allows you to use any database you want for your users and their data (including passwords). If you’re starting with a new user database, then ASP.NET Identity is one option you could choose
The way this is achieved is by creating a new project for ASP.NET Identity and configuring it to use Identity Server. A practical example can be found here. You can fork this repository and clone it and build it locally. You’ll need to have .NET Core 2.1 SKD in order to build and compile this solution. Pay special attention to the Startup.cs for the DbContext and IdentityRoles, as well as and Config.cs for resources and clients, as explained in detail here.
3. Users Management with IDS4 and a custom database
The case above is very useful when building the users database from scratch. But in practice it’s possible there’s an existing users database that doesn’t use the AP.NET Identity, and you need to implement IDS as an authorization and authentication service serving the client application(s) against this users database.
To achieve this, IDS4 offers the following interfaces that need to be implemented into your custom implementation of Identity Server:
On the implementation side, a ProfileService class will implement an IProfileService interface. ProfileService can spin-off a user manager class, which is typically responsible for authorization and can:
- Pull a user from the users list
- check the hash value of the password against the database
- verify the email address/user id combination against the database.
ProfileService has to implement the GetProfileDataAsync and IsActiveAsync methods. GetProfileDataAsync should load the claims for a user and IsActiveAsync is expected to indicate if a user is allowed to obtain tokens. More detail about this can be found here.
On the implementation side, a class named “ResourceOwnerPasswordValidator” should implement the interface “IResourceOwnerPasswordValidator”, which is used for authentication. The method that needs to be implemented here is ValidateAsync. The responsibility of this method is to check the UserName and Password in the database, to return the user if the verification is successful and null otherwise. More info here.
This reflects the high level of flexibility that Identity Server offers, by defining an extensibility point for allowing claims to be dynamically loaded as needed for a user. More detail and code examples can be found here.
Lastly, if you need any additional help, or have further questions regarding user management with Identity Server 4 and a custom database, please give us a call. We’d love to help you get started.