How to Use ASP.NET Identity

Introduction

Identity configuration in ASP.NET can be quite confusing, especially if you want to customize setup properties.

When you use a code-first approach using Entity Framework, you have full control over your user identity options. However when developers deal with bigger projects, they typically prefer to use a table-first approach in which they create the database, then consume the information in the API, and lastly shape it in a way that it makes sense on the front end.

Be careful when you determine your Data Source. If you’re using a local instance of SQL Server, stick with the default data source, or .. If you’re using an Azure database or other type of service, look at sample connection strings before proceeding further.

The next step is to create our own database context, which we can use for storing our users and their properties. In the Models\IdentityModels.cs, we are going to delete the ApplicationDbContext and paste the following code on its place.

public class AppUsersDbContext : IdentityDbContext<ApplicationUser>
{
    public AppUsersDbContext()
        : base("SystemUsers", throwIfV1Schema: false)
    {
    }

    public static AppUsersDbContext Create()
    {
        return new AppUsersDbContext();
    }
}

As you can see, we use the new connection from the Web.config file for the new context by passing its name as a string.

Once we have the connection between the database and the ASP.NET project, we should configure the built in ApplicationUserManager, so it uses this context instead of the default one, which we have already deleted.

A quick look at both the UserStore and the ApplicationUserManager classes:

namespace Microsoft.AspNet.Identity.EntityFramework
{
   //
   // Summary:
   // EntityFramework based user store implementation that supports IUserStore, IUserLoginStore,
   // IUserClaimStore and IUserRoleStore
   //
   // Type parameters:
   // TUser:
   public class UserStore<TUser> : UserStore<TUser, IdentityRole, string, IdentityUserLogin, IdentityUserRole, IdentityUserClaim>, IUserStore<TUser>, IUserStore<TUser, string>, IDisposable where TUser : IdentityUser
   {
      //
      // Summary:
      // Default constuctor which uses a new instance of a default EntityyDbContext
      public UserStore();
      //
      // Summary:
      // Constructor
      //
      // Parameters:
      // context:
      public UserStore(DbContext context);
   }
}

namespace WebApi
{
    // Configure the application user manager used in this application. UserManager is defined in ASP.NET Identity and is used by the application.

    public class ApplicationUserManager : UserManager<ApplicationUser>
    {
        public ApplicationUserManager(IUserStore<ApplicationUser> store)
            : base(store)
        {
        }

        public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
        {
            ///Calling the non-default constructor of the UserStore class
            var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));

            /// Rest of the class ...
        }
    }
}

The ApplicationUserManager calls the constructor of the UserStore, which accepts a DbContext. Then it uses this connection to store the user’s data. So, here it is enough just to pass our custom context as a parameter, when the ApplicationUserManager calls the UserStore constructor.

Substitute the manager variable with the following code:

The next step is to initialize our context each time our application starts, so that the user manager and the context use the same instance.

Go to the AppStart\Startup.Auth.cs file, where we can see that currently, only the deleted ApplicationDbContext is initialized.

public void ConfigureAuth(IAppBuilder app)
{
    // Configure the db context and user manager to use a single instance per request
    app.CreatePerOwinContext(ApplicationDbContext.Create);
    app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);

    // Enable the application to use a cookie to store information for the signed in user
    // and to use a cookie to temporarily store information about a user logging in with a third party login provider
    app.UseCookieAuthentication(new CookieAuthenticationOptions());
    app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);

    /// Rest of the class ...
}

The route for our new endpoint will be users/{id:guid}/roles. An ID and an array of roles should be the request parameters.

Finally, make an instance of our ApplicationRoleManager. To do this, add this code snippet in the AccountController

public class AccountController : ApiController
{
    ///...
    private ApplicationRoleManager _roleManager;
    ///...
    public AccountController(ApplicationUserManager userManager,
        ISecureDataFormat<AuthenticationTicket> accessTokenFormat, ApplicationRoleManager roleManager)
    {
    ///Make an instance of the user manager in the controller to avoid null reference exception
        UserManager = userManager;
        AccessTokenFormat = accessTokenFormat;
        ///Make an instance of the role manager in the constructor to avoid null reference exception
        RoleManager = roleManager;
    }
///...
    public ApplicationRoleManager RoleManager
    {
        get
        {
            return _roleManager ?? Request.GetOwinContext().GetUserManager<ApplicationRoleManager>();
        }
        private set
        {
            _roleManager = value;
        }
    }
/// Rest of the class...
}

By now, we have developed a fully-functional User Accounts system that is able to maintain user registration and different roles.

Now, let’s add some additional fields to our accounts system. To keep things simple, I will create just two additional columns in the AspNetUsers table. The first one will be IsDeleted, a BIT column that will serve as a marker used for soft deletion.

The second column will be CompanySecretCode, an encrypted column that keeps a code that each user can use to access different documents (there is no particular reason for putting such a column in our table, it is just an example of how to encrypt columns when it comes to accounts system).

In soft deletion, we mark an entity as “deleted” but don’t actually remove it from the database until we decide that it is extraneous.

Since the package that we are using implements code-first migrations, it is enough just to add the IsDeleted column to our ApplicationUser class and then clearly define its default value and further usage. First, open AppStart\IdentityConfig.cs file and add the property:

public class ApplicationUser : IdentityUser
{
    // Property used for soft deleting users
    public bool IsDeleted { get; set; }
    public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager, string authenticationType)
    {
        // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType
        var userIdentity = await manager.CreateIdentityAsync(this, authenticationType);
        // Add custom user claims here
        return userIdentity;
    }
}

After this, we can start using our new column immediately. The first and most obvious thing to do is to assign a value to this property when we create the user. For this purpose, replace the Register method in the AccountController with the following code:

 // POST api/Account/Register
[AllowAnonymous]
[Route("Register")]
public async Task<IHttpActionResult> Register(RegisterBindingModel model)
{
    if (!ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }

    var user = new ApplicationUser() { UserName = model.Email, Email = model.Email };

    //set the IsDeleted property to false
    user.IsDeleted = false;

    IdentityResult result = await UserManager.CreateAsync(user, model.Password);

    if (!result.Succeeded)
    {
        return GetErrorResult(result);
    }

    return Ok();
}

Since we have changed our default ApplicationUser class and our database still does not know about it, we should see an exception when we try to add a new user. The exception reads: ‘Consider using Code First Migrations to update the database.’

We should execute a migration that will create the IsDeleted column in our database. Before doing this, delete the user we have created because it does not have the IsDeleted column and this is going to be an obstacle when we try to make it non-nullable. Next:

• Open the Package Manager Console.

• Set the Default Project property to WebApi.

• Enable migrations by targeting our custom context: Enable-Migrations -contexttypename AppUsersDbContext

• Add a migration: Add-Migration Initial

• Update-Database

These commands should execute a migration that creates the needed column in the database. Moreover, you should have a new folder called Migrations in your WebApi project. There you can see all migrations that you have executed and you can write new ones, in case you need them.

This is the migration code we used above:

Since developers usually use User Accounts and Roles when they want to secure the access to different parts of their applications, ASP.NET is not an exception and you can allow different types of ApplicationUsers (or different Roles in our case) to be allowed access to some endpoints and denied access to others.

Example