How to change type of id in Microsoft.AspNet.Identity.EntityFramework.IdentityUser

Question

(ASP.NET MVC 5, EF6, VS2013)

I'm trying to figure out how to change the type of the "Id" field from string to int in the type:

Microsoft.AspNet.Identity.EntityFramework.IdentityUser 

in order to have new user accounts be associated with an integer ID rather than a GUID. But it seems like this will be more complicated than simply adding a new Id property with type int in my derived user class. Take a look at this method signature:

(from Assembly Microsoft.AspNet.Identity.Core.dll)

public class UserManager<TUser> : IDisposable where TUser : global::Microsoft.AspNet.Identity.IUser   {   ...   public virtual Task<IdentityResult> AddLoginAsync(string userId, UserLoginInfo login);   ...   } 

So it seems that there are other methods baked into the ASP.NET identity framework which require the userId to be a string. Would I need to reimplement these classes as well?

An explanation of why I don't want to store GUIDs for ids in the user table:

-There will be other tables that relate data to the users table via a foreign key. (When users save content on the site.) I see no reason to use the larger field type and spend extra database space with no clear advantages. (I know that there are other posts about using GUIDs vs int ids, but it seems like many suggest that int ids are faster and use less space, which still leaves me wondering.)

-I plan to expose a restful endpoint to allow users to retrieve data about a particular user. I think:

/users/123/name 

is cleaner than

/users/{af54c891-69ba-4ddf-8cb6-00d368e58d77}/name 

Does anyone know why the ASP.NET team decided to implement IDs this way? Am I being short sighted in trying to change this to an int type? (Perhaps there are benefits I'm missing.)

Thanks...

-Ben

Answer 1

Using a Stefan Cebulak's answer and a Ben Foster's great blog article ASP.NET Identity Stripped Bare I have came up with below solution, which I have applied to ASP.NET Identity 2.0 with a generated by Visual Studio 2013 AccountController.

The solution uses an integer as a primary key for users and also allows to get an ID of currently logged in user without making a trip to the database.

Here are the steps, you need to follow:

1. Create custom user-related classes

By default, the AccountController uses classes, which are using string, as a type of a primary key. We need to create below classes, which will use an int instead. I have defined all below classes in one file: AppUser.cs

public class AppUser :     IdentityUser<int, AppUserLogin, AppUserRole, AppUserClaim>,     IUser<int> {  }  public class AppUserLogin : IdentityUserLogin<int> { }  public class AppUserRole : IdentityUserRole<int> { }  public class AppUserClaim : IdentityUserClaim<int> { }  public class AppRole : IdentityRole<int, AppUserRole> { } 

It will also be useful, to have a custom ClaimsPrincipal, which will easily expose User's ID

public class AppClaimsPrincipal : ClaimsPrincipal {     public AppClaimsPrincipal( ClaimsPrincipal principal ) : base( principal )     { }      public int UserId     {         get { return int.Parse(this.FindFirst( ClaimTypes.Sid ).Value); }     } } 

2. Create a custom IdentityDbContext

Our application's database context will extend IdentityDbContext, which implements by default all authentication-related DbSets. Even if DbContext.OnModelCreating is an empty method, I am not sure about the IdentityDbContext.OnModelCreating, so when overriding, remember to call base.OnModelCreating( modelBuilder ) AppDbContext.cs

public class AppDbContext :     IdentityDbContext<AppUser, AppRole, int, AppUserLogin, AppUserRole, AppUserClaim> {     public AppDbContext() : base("DefaultConnection")     {         // Here use initializer of your choice         Database.SetInitializer( new CreateDatabaseIfNotExists<AppDbContext>() );     }       // Here you define your own DbSet's        protected override void OnModelCreating( DbModelBuilder modelBuilder )     {         base.OnModelCreating( modelBuilder );          // Here you can put FluentAPI code or add configuration map's     } } 

3. Create custom UserStore and UserManager, which will use above

AppUserStore.cs

public interface IAppUserStore : IUserStore<AppUser, int> {  }  public class AppUserStore :     UserStore<AppUser, AppRole, int, AppUserLogin, AppUserRole, AppUserClaim>,     IAppUserStore {     public AppUserStore() : base( new AppDbContext() )     {      }      public AppUserStore(AppDbContext context) : base(context)     {      } } 

AppUserManager.cs

public class AppUserManager : UserManager<AppUser, int> {     public AppUserManager( IAppUserStore store ) : base( store )     {      } } 

4. Modify AccountController to use your custom classes

Change all UserManager to AppUserManager, UserStore to AppUserStore etc. Take an example of this constructors:

public AccountController()     : this( new AppUserManager( new AppUserStore( new AppDbContext() ) ) ) { }  public AccountController(AppUserManager userManager) {     UserManager = userManager; } 

5. Add user's ID as a claim to ClaimIdentity stored in a cookie

In step 1, we have created AppClaimsPrincipal, which exposes UserId taken out of ClaimType.Sid. However, to have this claim available, we need to add it, when logging in the user. In AccountController a SingInAsync method is responsible for logging in. We need to add a line to this method, to add the claim.

private async Task SignInAsync(AppUser user, bool isPersistent) {     AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);     ClaimsIdentity identity = await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);      // Extend identity claims     identity.AddClaim( new Claim( ClaimTypes.Sid, user.Id.ToString() ) );      AuthenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = isPersistent }, identity); } 

6. Create a BaseController with a CurrentUser property

To have an easy access to a currently logged in user's ID in your controllers, create an abstract BaseController, from which your controllers will derive. In the BaseController, create a CurrentUser as follows:

public abstract class BaseController : Controller {     public AppClaimsPrincipal CurrentUser     {         get { return new AppClaimsPrincipal( ( ClaimsPrincipal )this.User ); }     }       public BaseController()     {      } } 

7. Inherit your controllers from BaseController and enjoy

From now on, you can use CurrentUser.UserId in your controllers to access an ID of a currently logged in user without trips to the database. You can use it, to query only objects, which belong to the user.

You don't have to take care of auto generation of user primary keys - no surprise, Entity Framework by default uses Identity for integer primary keys, when creating tables.

Warning! Keep in mind, that if you implement it in already released project, for already logged in users ClaimsType.Sid will not exist and FindFirst will return null in AppClaimsPrincipal. You need to either force logout all users or handle this scenario in AppClaimsPrincipal