Setup Asp.NET Identity DB with Entity Framework
This post walks through the steps required to setup Asp.NET 5.0 database and entities
What is Asp.NET Identity?
Asp.NET identity provides a comprehensive set of identity functions that most applications need on a day to day basis, such as account creation, activation, password reset, token refresh, etc. Necessary for all these functions is the identity database and its entities, which holds our user data. In this post, I walk you through how to set up the identity DB using Entity Framework.
By the way, this topic belongs to the series to set up Authentication and Authorisation for Asp.NET ecosystem.
- Asp.Net Core Web Api Setup
- React Single Page App Setup
- Asp.NET Identity DB Setup
- Email Sender
- Sign Up & Activation
- Check User Authentication Status
- Change Password
- Sign In
- Policy Based Access Management
- Token Refresh
- Google Authentication with React and Asp.NET API
- Microsoft Authentication with React and Asp.NET API
- Twitter Authentication with React and Asp.NET API
Before we begin, there are some prerequisites which you need to read first as I will build on top of them:
- Secret management for Asp.NET 5 APIs with Azure KeyVault
- Database setup for Asp.NET 5.0 Web API with Entity Framework and SQL Server
1. Identity Entities
I have covered some of the basic Entity Framework set up here, so I skip all that, and I will jump into Identity entities.
I have put my Identity entities inside the DataAccess project, as I have assumed this project is going to scale, I have defined individual classes for each entity, to which you can add your own database fields:
1.1 Entity: Application Entity
Below you can find our first or probably the most important entity, ApplicationUser.
There are some points I’d like to address here about the above snippet, which are common for the rest of our entities as well:
- IdentityUser base class: My Application User inherits a lot of common user attributes from IdentityUser, and among them are Phone Number, Email, Username, etc. They are there, so I don’t have to create them again in my ApplicationUser.
- Primary Key type: IdentityUser, like the rest of Identity base classes, has been defined generic, so you could pass the type of PrimaryKey you need. For some applications integer would be enough, but for some other platforms which could generate increasing number of rows (like AuditLogs), you might need to consider Guid.
- Add Attributes: Beside defining the type of primary key, the other reason behind creating a custom class is to define all the attributes I need as part of my application. In my case, I have added PlanId, and user Devices.
Domain Driven Microservices
I have defined the attribute called PlanID, but there is no such entity in the list of my Identity entities. The reason is I am following Domain Driven Microservices approach, in which each Microservice specialises in one domain, and takes care of its own data and services, and if it needs to refer to another domain, it just holds a reference to the entity managed by other domains’ microservices (in this case Payment Plans managed by Subscription Microservice).
You might argue this is creating dependency on another microservice, however this is just a nullable data reference, and hence my Identity API can function on its own. In the case it needs to fetch the PlanInformation from Subscription API for a good reason (to generate claims and put them inside the JWT token), it will call that microservice and fetch the detailed plan attributes for the user. I will cover this topic in another post extensively.
1.2 Entity: ApplicationRole
The next entity is ApplicationRole, which I have defined as below, and it contains no additional attributes, as I was happy with what was already in IdentityRole base class.
The rest of entities I have defined the same way are:
There also could be entities that you don’t need to inherit from any base class, such as my ApplicationUserDevice, and you define and include them as you go.
2. Identity Db Context
Next I need to create my Identity DbContext, which has a reference to some of the entities we defined here. Some points to highlight in this Identity Db Context:
- IdentityDbContext base class: Unlike the general DbContext, when it comes down to Asp.NET Identity we need to use the IdentityDbContext which accepts the custom entities we defined above in the form of generic types.
- DbSets: For those entities which I defined above, and are not passed as a genetic argument, they need to be included in this class as DbSets, such as ApplicationUserDevices.
- Constructor Arguments: The type of argument passed to the constructor also needs to be of IdentityDbContext type.
Configuration, plumbing and troubleshooting your software foundation take a considerable amount of time in your product development. Consider using Pellerex which is a complete foundation for your enterprise software products, providing source-included Identity and Payment functions across UI (React), API (.NET), Pipeline (Azure DevOps) and Infrastructure (Kubernetes).
3. Configure Services
Last but not least, I need to define and inject the Identity Db services into my DI ecosystem. Below is the function that I have used to do so, and here are some notes about it:
- Migration Assembly: As I have put my IdentityDbContext in DataAccess assembly, and that contains my migrations, I need to include the name of the assembly here.
- AddIdentity Method: AddIdentity method is used to introduce ApplicationUser and ApplicationRole entities and initiate the Identity function with our newly created IdentityDbContext.
- Configure identity behavior: And at the end I can configure the behaviour of the system, such as how to validate new accounts’ passwords or if they need email confirmation, etc. using the Configure method.
For further readings on how to update the database after making all these changes, refer to Database setup for Asp.NET 5.0 Web API with Entity Framework and SQL Server.
How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.
Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.
Check out Pellerex and talk to our team today to start building your next enterprise software fast.