Solution 1:

If you really want to use e-mail address to log in, then, IMHO, the "hack" you suggested is the best approach. Because, if you insist on "doing it properly" you'll have to at least

  • modify the database schema, obviously
  • ensure username uniqueness yourself (you could make a database constraint/index do this for you, but you'll have to find a good way to deal with errors and reporting them to the user)
  • find a good substitute for just writing "User.Identity.UserName" in you code
  • probably even more

On the other hand, if you decide to "hack" the UserName field you need to

  • modify RegisterViewModel validation (add [EmailAddress] to the UserName property), probably slightly customize [Display(Name=...)] etc.
  • make sure UserManager.UserValidator instance used in your AccountController allows special characters used in e-mail addresses. To do this, make sure its nondefault constructor looks like this:

    public AccountController(UserManager<ApplicationUser> userManager)
    {
        UserManager = userManager;
        var userValidator = UserManager.UserValidator as UserValidator<ApplicationUser>;
        userValidator.AllowOnlyAlphanumericUserNames = false;
    }
    

I hope this could help you weigh the pros and cons of both approaches and come up with the best solution. Good luck!

Solution 2:

Bit late to the party, but I thought I'd throw in my $0.02.

While it's true that UserName and Email are both part of IdentityUser and thus are required, note that they are both marked as virtual. If you want UserName and Email to be the the email address, let the ApplicationUser model encapsulate the logic like so:

public class ApplicationUser : IdentityUser
{
    private string _userNameEmailBackingField;

    public override string UserName
    {
        get { return _userNameEmailBackingField; }
        set { _userNameEmailBackingField = value; }
    }

    public override string Email
    {
        get { return _userNameEmailBackingField; }
        set { _userNameEmailBackingField = value; }
    }

    //The rest of your ApplicationUser logic
}

Then in your view model, expose only a single property and map it to either/or in your ApplicationUser instance, ensuring that you decorate the view model property with [Required] and [EmailAddress] attributes.

As others have mentioned, you'll need to ensure that AllowOnlyAlphanumericUserNames is set to false for the UserManager's UserValidator, but I you get that out of the box with the newest web template in VS2013.

Solution 3:

I'm currently working on this feature for the Identity 1.1 templates which will switch to email and add account confirmation/forgot password functionality, and the two options we considered was the hack (use username as email with validation) and adding an additional email field which is separate from the username which is what we are leaning towards.

Its likely that there will be a few email specific apis added in 1.1 to the UserManager:

FindByEmail
SetEmail
GetEmail