Is it possible to make the Identity entity generic so that users can extend the Identity field themselves?

[easy999000]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Is it possible to make the Identity entity generic so that users can extend the Identity field themselves?
For example: public class IdentityUserManager<T> : UserManager<T>, IDomainService

Describe the solution you'd like

I would like to extend the identity field to make it easier to add custom fields.
This is because I plan to integrate multiple user systems into my system, each using different tables.

Defining different extension classes will make it easier to distinguish between user types.

Additional context

https://github.com/abpframework/abp/blob/dev/modules/identity/src/Volo.Abp.Identity.Domain/Volo/Abp/Identity/IdentityUserManager.cs

[maliming]

Hi,

Thanks for the suggestion, but making IdentityUserManager generic isn't something we plan to do. IdentityUser is referenced in ~245 places across the Identity module, and IdentityUserStore implements 13 IUser*Store<IdentityUser> interfaces. Downstream modules like Account, OpenIddict, AuditLogging and the App Services / DTOs / ObjectMapper all rely on the concrete IdentityUser type. Turning it generic would be a huge breaking change for every project that already extends or overrides IdentityUserManager, and it still wouldn't fully solve your case (you'd also need a generic store, repository, DbContext mapping, app service, permission scope, etc.).

For your scenario, there are a few paths depending on what you actually need:

1. Just adding a few custom fields to IdentityUser → use the entity extension system (ObjectExtensionManager.AddOrUpdateProperty<IdentityUser, T>(...)). It persists to the same AbpUsers table automatically. See: https://abp.io/docs/latest/framework/architecture/modularity/extending/entity-extensions

2. Adding properties but keeping the same AbpUsers table → derive your own class from IdentityUser and re-map it in EF Core. See: https://abp.io/docs/latest/framework/architecture/modularity/extending/customizing-application-modules-extending-entities

3. Multiple user systems with completely separate tables / fields → this is outside what the Identity module is designed for. The cleaner approach is to model the secondary user system as its own aggregate root (your own entity + manager + repository + table), and use ABP's external login providers if you need cross-system authentication. Trying to bend Identity to host a second parallel user type tends to fight the framework more than help.

Hope this helps.

Thanks.

[easy999000]

thanks