Pfthb

env: Asp Core, Entity-framework

In my system I have two types

[Table("User")]
ApplicationUser : IdentityUser<Guid>

[Table("Customer")]
Customer : IdentityUser<Guid>

Both entities(Customer and User) have many different fields, what makes using only one table in a Database not correct. And both entities must have possibility to do sign in.

As I found ASP Net can have only one identity setup.

Question: What is the best way or best practices to make this stuff work?

The best approach would be to use seperate contexts. Please note that login is part of Identity. Create a login user here for login.

My advice is to keep Identity as is in it's own context and create the User and Customer table in the business context. This means you can't inherit from IdentityUser.

In order to link the login user to the business User / Customer, simply add a field sub which contains the SubjectId of the current user. In that case the login user can be linked to the user / customer in the business context.

Aside, you'll only need the User table when it contains information to show on reports, e.g. username of the user that last updated the field. The Identity user table is not accessible from this context and you should keep it that way.

On the other hand the current user can be identified by the UserId / SubjectId claim, or sub claim in OpenIdConnect. So you don't need an actual relation between the users in both contexts. A reference on the sub will do.

I suggest you not try to mix or unify Identity of application user and meanings of application user from another boundary contexts of you application.

Identity record of application user is his representation from security perspective, and it is used for identification/authentication of user. So it contains user security data, its access roles and other security claims. Any Identity record can have very specific access right based on his roles and claims and usually it is enough.

If you need to represent application user from another perspective (as your employ, or as you customer, maybe as guest record, etc.) then it is better to create another table (Employees, Customers, Guests , etc.) for it in another DbContext (not in Identity context). It will give you possibility not to mix their conceptual borders. Who knows, maybe at some moment you will decide to create separated microservices for each boundary context and Identity will serve them all as another microservice.

If you asking now yourself how to organize such parallel storing of interpretations of the same application user, then there are different approaches. But for example:

• When user is registering you create Identity for him


• When he is logged-in he use his Identity data for authentication


• But when he create his first order you create Customer record for him that has same Id as his Identity, or has foreign key to Identity, or... the rest depends on your needs and business logic.