Take the community feedback survey now.

Upgrading to Episerver 12: how to manage custom user and role tables

Vote:
 

We are currently upgrading an episerver 11 site to 12 for a customer. The current site uses Entra for login (OpenId) and custom tables for users, roles and userrole mappings. To manage the custom tables there are custom MembershipProvider and RoleProvider classes and quite a bit of custom code. 

We are trying to find the best way to migrate to using AspNetIdentity instead, so we have some questions:

  1. Is it possible to use AddCmsAspNetIdentity with our existing custom tables for user, roles and user/role mappings? If yes, how?
  2. Is there some other way to make Episerver use our custom implementation, for example can Episerver be made to work with IUserStore, IRoleStore etc instead (the core equivalent of MembershipProvider and RoleProvider as far as we understand)? If yes, how?
  3. Is there any other option apart from migrating all existing data (and rewrite a whole lot of code) to use the standard tables for AspNetIdentity?

 

Thanks, Peter

#340086
Edited, Aug 25, 2025 8:44
Vote:
 

Hi Peter, I'll try to give answers that might help you or at least lead you in right direction:

1) If your user model should contain additional properties, you need to extended ApplicationUser model with your own, but you'll also need to write a custom ApplicationUserManager that knows how to deal with those additional tables and user data, also EF migration is needed for additional user properties. Are those custom tables added using Entity Framework, do you have migrations in project?

2) You can investigate following classes and possibly extend them or replace with custom one: ApplicationUserProvider, ApplicationUserManager, ApplicationRoleProvider, ApplicationRoleManager.

3) If you want to use standard tables your are stuck with properties that are default by Identity server, but as I can see, you need additional user data and that means you'll need to implement your custom classes that extend those built-in properties and implementation.

You can also use virtual (NotMapped) properties as part of ApplicationUser model where those additional properties are only getters for data coming from Azure Entra that are resolved in the runtime, so they don't need to be stored in Optimizely DB at all.

#340100
Edited, Aug 25, 2025 16:36
Peter Törnqvist - Aug 29, 2025 11:52
Thanks for a great write up. It looks like #2 might be the one we should start investigating. If that doesn't work out, #1 might be the way to go

Thanks again!
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.