ASP.NET Core 3.1 MVC で ASP.NET Identity をユーザー認証に使用し、Email Confirmation と Password Recovery を実装する際、自分的に気になったことを備忘録として書いておきます。

（.NET Framework 版については特に気を付ける点はなさそうなので割愛します。手抜きですみません。基本的な枠組みが Visual Studio のテンプレートで生成されるコードに含まれており、Microsoft のチュートリアル「ログイン、電子メール確認、パスワード リセットを使用して安全な ASP.NET MVC 5 Web アプリを作成する (C#)」に従って生成されたコードに手を加えれば特に苦労なく実装できると思います。　2021/3/14 追記: SendGrid は id と password による認証をサポートしなくなりました。なので、.NET Framework 版 MVC5 の場合もこの記事に書いた Api Key による認証とする必要がありますので注意してください）

基本的には Microsoft のチュートリアル Account confirmation and password recovery in ASP.NET Core に従って実装しますので、詳しくはそのドキュメントを見てください。そのドキュメントの説明だけではよく分からないと思った点を以下に書きます。

(1) プロジェクトの作成

Visual Studio 2019 のテンプレートを利用して ASP.NET Core 3.1 MVC アプリを作成します。

認証関係のソースコードに手を加えるので、アプリ作成の際に認証は「認証なし」のままとしておき、スキャフォールディング機能を利用して ASP.NET Identity を実装し、ソースコードがプロジェクトに含まれるようにします。

詳しい手順は先の記事「ASP.NET Identity で MySQL 利用 (CORE 版)」のステップ「(1) プロジェクトの作成」とステップ「(2) ASP.NET Core Identity の実装」を見てください。

(2) Email Confirmation 実装前の動き

上のステップ (1) でプロジェクトを作成直後（Email Confirmation を実装する前）のユーザー登録の仕組み説明します。それを理解しておいた方がこの後の説明が分かりやすいと思いますので。仕組みをご存じの方はここはスキップして (3) に進んでください。

デフォルトで options.SignIn.RequireConfirmedAccount が true に設定されており（そのコードは Areas/Identity/IdentityHostingStartup.cs にあります）、ユーザー登録に使用する Register ページも Email Confirmation を使用する前提でコーディングされています。ちなみに false に設定すると登録後直ちにログイン状態になります。

Areas/Identity/Pages/Account フォルダにある Register.cshtml.cs を開いて OnPostAsync メソッドのコードを見てください。登録画面にユーザーが email と password を入力して送信するとそのメソッドでユーザー登録処理が行われます。

ユーザー登録に成功すると RegisterConfirmation ページにリダイレクトされます。（実際はリダイレクト前に _emailSender.SendEmailAsync メソッドが実行されますが、デフォルトではメール送信機能は実装されていないので何も起こりません。何故かエラーも出ません）

RegisterConfirmation ページは下の画像のように表示されます。

上の画像の "Click here to confirm your account" には ConfirmEmail ページへのリンクが張ってあり、クエリ文字列に UserId とトークンが設定されています。

リンクをクリックすると ConfirmEmail ページが GET 要求され Areas/Identity/Pages/Account フォルダにある ConfirmEmail.cshtml.cs の _userManager.ConfirmEmailAsync(user, code) メソッドで Email Confirmation が実行（AspNetUsers テーブルの EmailConfirmed フィールドが True に更新）されます。

Email Confirmation に成功すると下の画像の ConfirmEmail ページが表示されます。

この後、右上の [Login] をクリックして Login ページを表示し、登録した email と password を入力してログインできるようになります。

Email Confirmation を実装してメールを送信できるようにすると、ConfirmEmail ページへのリンク（UserId とトークンのクエリ文字列を含む）が本文に含まれたメールが自動的に送信され、それをクリックすると ConfirmEmail ページが GET 要求されて Email Confirmation が実行されるようになります。

RegisterConfirmation ページへのリダイレクトは同様に起こりますが、それには ConfirmEmail ページへのリンクは含まれず、単に "Please check your email to confirm your account." と表示されただけものになります。

以下のステップ (3) 以降にメールの自動送信を含む Email Confirmation の実装方法を述べます

(3) API Key の入手

チュートリアルに従って、メールの送信には SendGrid を利用します。ユーザー登録して API Key を入手してください。

SendGrid は基本的に有償ですが、開発目的限定で送信する量が少ない場合は Free のサービスでよさそうです。Pricing のページを見てください。

(4) SendGrid のインストール

NuGet を利用してプロジェクトに SendGrid をインストールします。

上の画像ではバージョンが 9.12.6 となっていますが、自分が試したときはそれが最新版だったということで、意図的にそのバージョンを選んだわけではありません。

(5) User Secrets

メールの差出人と SendGrid の API Key をユーザーシークレットに設定します。チュートリアルは dotnet コマンドを使っていますが、Visual Studio のソリューションエクスプローラーから開いて設定できます。

上の画像のように操作すると secrets.json ファイルが開くので、それに以下のようにメールの差出人と SendGrid の API Key を設定して保存します。

appsettings.json に設定しても取得できますが、チュートリアルでは、開発時に、Password その他の機密データを秘密の場所に保存できることを紹介する意味でユーザーシークレットを使っているようです。

ユーザーシークレットは開発時の開発マシンのでの利用に限られます。secrets.json ファイルは開発マシンの開発者のユーザープロファイルフォルダー内にあるので当たり前ですが・・・　詳しくは Safe storage of app secrets in development in ASP.NET Core を見てください。

チュートリアルには AuthMessageSenderOptions クラスの追加と Startup.ConfigureServices へのコードの追加を行うように書かれています。

まず、プロジェクトルート直下に Services フォルダを追加し、その中にクラスファイル AuthMesageSenderOptions.cs を追加します。コードはチュートリアルのものをコピペします。

// AuthMessageSenderOptions クラスの追加

namespace MySQLIdentity.Services
{
    public class AuthMessageSenderOptions
    {
        public string SendGridUser { get; set; }
        public string SendGridKey { get; set; }
    }
}

次に、Startup.cs の ConfigureServices メソッド内に以下のコードを追加します。

// Startup,cs の ConfigureServices メソッド内に追加

services.Configure<AuthMessageSenderOptions>(Configuration);

これらは、AuthMessageSenderOption クラスを、必要に応じて初期化してそのオブジェクトを DI によって注入するために必要なもののようです。

その設定により、secrets.json ファイルに設定した差出人と API Key 情報は、EmailSender クラスを初期化する際に DI によって注入された AuthMessageSenderOption オブジェクトから取得できます。

なお、secrets.json ファイルを使わなくても、普通に appsettings.json に差出人と API Key 情報を設定しても同様に DI によって取得できます（secrets.json と appsettings.json の��方から探してくるようです）。運用環境にデプロイする際に appsettings.json に移すということではなさそうですが、実際どうすべきかは調べておらず不明です。

(6) EmailSender クラスの実装

メールを送信するため IEmailSender インターフェイスを継承した EmailSender クラスを実装します。

チュートリアルに従ってクラスファイル Services/EmailSender.cs を追加し、それにチュートリアルのコードをそのままコピペしてください。

念のため、以下にコードを貼っておきます。

using Microsoft.AspNetCore.Identity.UI.Services;
using Microsoft.Extensions.Options;
using SendGrid;
using SendGrid.Helpers.Mail;
using System.Threading.Tasks;

namespace MySQLIdentity.Services
{
    public class EmailSender : IEmailSender
    {
        public EmailSender(IOptions<AuthMessageSenderOptions> optionsAccessor)
        {
            Options = optionsAccessor.Value;
        }

        public AuthMessageSenderOptions Options { get; }

        public Task SendEmailAsync(string email, string subject, string message)
        {
            return Execute(Options.SendGridKey, subject, message, email);
        }

        public Task Execute(string apiKey, string subject, string message, string email)
        {
            var client = new SendGridClient(apiKey);
            var msg = new SendGridMessage()
            {
                From = new EmailAddress("xxxxx", Options.SendGridUser),
                Subject = subject,
                PlainTextContent = message,
                HtmlContent = message
            };
            msg.AddTo(new EmailAddress(email));

            // Disable click tracking.
            // See https://sendgrid.com/docs/User_Guide/Settings/tracking.html
            msg.SetClickTracking(false, false);

            return client.SendEmailAsync(msg);
        }
    }
}

上のコード From = new EmailAddress("xxxxx", Options.SendGridUser) の xxxxx をメールの差出人のメールアドレスに変更してください。

EmailSender クラスが初期化される際に DI により AuthMessageSenderOptions オブジェクトが注入され、差出人と API Key 情報が取得できるようにコーディングされています。

EmailSender クラスは Register ページと ForgotPassword ページでメールを送信する際に使用されます。その際、DI により EmailSender クラスを初期化してそのオブジェクトを注入するコーディングになっています。それを可能にするため、Startup.cs の ConfigureServices メソッド内に以下のコードを追加します。

// Startup.cs の ConfigureServices メソッド内に追加

services.AddTransient<IEmailSender, EmailSender>();

上記の Startup.cs への設定を忘れるとメール送信機能は動きませんので注意してください。

(7) Register ページの修正

Areas/Identity/Pages/Account フォルダの Register.cshtml.cs を開いて OnPostAsync メソッドのコードを見てください。

ユーザー登録に成功すると変数 callbackUrl に UserId とトークン情報がクエリ文字列として設定された /Account/ConfirmEmail ページへの URL 文字列が設定されます。

デフォルトでは html の a 要素の href 属性にその URL が設定されたメール本文がユーザーが email として登録したメールアドレスに送信されます。

ユーザーが使っているメーラーが html を表示できる設定になっていれば、その a 要素で "clicking here" と表示されるリンクをクリックすれば ConfirmEmail ページが GET 要求され、クエリ文字列に設定された UserId とトークンで Email Confirmation が行われ、ブラウザが立ち上がって ConfirmEmail ページが表示されます。

ユーザーのメーラーが html の表示を許可していない可能性を考えて、html の a 要素を組み立てて送るのではなく、URL そのものを送信したい場合は以下のようにします。

await _emailSender.SendEmailAsync(Input.Email, "Confirm your email",
    "Please confirm your account by: " + 
    HtmlEncoder.Default.Encode(callbackUrl).Replace("&", "&"));

その際、その際クエリ文字列内の & は & にしないと ConfirmEmail の OnGetAsync(string userId, string code) の code が null になってしまうので注意してください。

上記の結果、送信されたメールは以下の画像のようになります。（メーラーは Windows Live メールです）

(8) RegisterConfirmation ページの修正

Areas/Identity/Pages/Account フォルダの RegisterConfirmation.cshtml.cs を開いて OnGetAsync メソッドを以下のように修正します。

Email Confirmation を実装したので ConfirmationEmail ページへのリンクを表示する必要はありません。そのリンクを生成するコードをコメントアウトします。

加えて DisplayConfirmAccountLink を falses に設定し、ConfirmationEmail ページへのリンクではなくて単に "Please check your email to confirm your account." と表示されるようにします。

(9) Password Recovery

Password Recovery はユーザーがパスワードを忘れてしまっても復活できる手段を提供するものです。

上のステップ「(6) EmailSender クラスの実装」 まででメールは送信されるようになっていますので、基本的な機能だけなら既存のコードに手を加える必要はありません。

なお、スキャフォールディングで実装されるコードはメール送信機能を実装しないと Password Recovery が使えないコーディングになっていますので注意してください。（メール送信機能なしで Password Recovery を利用するにはコードを書き換える必要があります）

以下に Password Recovery がどのような動きになるかを説明しようと思いましたが、長くなりすぎるので別の記事「Password Recovery (CORE 版)」に書きました。興味があればそちらを見てください。

ASP.NET Identity ベースのフォーム認証を実装した ASP.NET MVC5 アプリケーションで、管理者がロール管理を行う機能を実装する例を書きます。先の記事「ASP.NET Identity のユーザー管理 (MVC)」の続きです。

CodeZine の記事「ASP.NET Identityでユーザーに役割（ロール）を持たせる 」に、ASP.NET Web Forms アプリ用のユーザー管理画面を作る手順が載っていますが、その MVC 版です。

ベースとなるのは、先の記事「ASP.NET Identity のユーザー管理 (MVC)」と同様、Visual Studio 2015 Community で MVC のテンプレートを利用し、認証に「個別のユーザーアカウント」を指定して自動生成させたプロジェクトです。

それにロール情報の追加、変更、削除および登録済みユーザーのロールのアサインを行う機能を実装するには以下のようにします：

(1) コードの追加

ロール情報の追加、変更、削除を行うのに用いるクラスは、IdentityRole クラスと RoleManager<TRole, TKey> クラスです。

テンプレートで自動生成されたコードにはそれらのコードは含まれていませんので追記する必要があります。

具体的には、Models\IdentityModels.cs, App_Start\IdentityConfig.cs, App_Start\Startup.Auth.cs の 3 つの既存のファイルに、CodeZine の記事「ASP.NET Identityでユーザーに役割（ロール）を持たせる」を参考にコードを追加します。（記事のコードをそのままコピペすれば OK）

何を追加するかを簡単に書きますと、IdentityModels.cs, IdentityConfig.cs, Startup.Auth.cs の順に、以下の通りです。

1. IdentityRole クラスを継承した ApplicationRole クラスを IdentityModels.cs に追加。
2. RoleManager<TRole, TKey> クラスを継承した ApplicationRoleManager クラスを IdentityConfig.cs に追加。定義には ApplicationRoleManager クラスのインスタンスを生成して OwinContext に登録するための Create メソッドを含める。Create メソッドにはロールストアに何も定義されてない場合 Administrator という名前のロールを作成するコードも含まれています。
3. ApplicationRoleManager のインスタンスを生成して OwinContext に登録するコードを Startup.Auth.cs の ConfigureAuth メソッドに追加。これにより、Controller で HttpContext.GetOwinContext() メソッドにより OwinContext を取得し、それから Get<ApplicationRoleManager>() メソッドで ApplicationRolerManager オブジェクトを取得できるようになります。

(2) Migrations を実施

上記 (1) の作業後アプリを実行すると、先にユーザー情報を登録して EF Code First の機能で DB を生成済みの場合は以下のようなエラーが出ると思います。ちなみに、下の画像でエラーとなっている行は、上記 (1) - 2 で追加した Create メソッドでロールストアにあるロール情報を取得するものです。

その場合は Migrations 実施してから再度実行してください。

具体的には、Visual Studio のパッケージマネージャーコンソールで、Enable-Migrations コマンドを実行して Code First Migrations を有効にし、次に Update-Database –Verbose コマンドを実行して保留中の移行をデータベースに適用します。

(3) AspNetRoles テーブルの確認

上記 (2) でエラーなく無事実行できれば、以下の画像のようにロール情報のストアとなる AspNetRoles テーブルに Discriminator フィールドが追加され、「結果」ウィンドウに示すように Name が Administrator というレコードができているはずです。

(4) ロール管理用 Controller / View の実装

ロール情報の追加、変更、削除および登録済みユーザーのロールのアサインを行うための Controller / View を実装します。Controller の実装例を以下に示します。説明はコード内のコメントに書きましたので、それを見てください。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

// 上は自動生成されたもの。それに以下の名前空間を追加
using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.Owin;
using System.Net;
using System.ComponentModel.DataAnnotations;
using System.Threading.Tasks;
using Mcv5App2.Models;

namespace Mcv5App2.Controllers
{
  // 以下の RoleModel, UserWithRoleInfo, RoleInfo の 3 クラス
  // はここで利用する Model。Controller 内に定義したのは単に
  // 分けるのが面倒だから

  // アクションメソッド Create, Edit 用の Model
  public class RoleModel
  {
    [Required]
    [StringLength(
      100, 
      ErrorMessage = "{0} は {2} 文字以上",
      MinimumLength = 3)]
    [Display(Name = "Role")]
    public string Role { get; set; }
  }

  // アクションメソッド UserWithRoles, EditRoleAssignment
  //  (各ユーザーのロール一覧表示、ロールのアサイン・削除) 
  // 用の Model
  public class UserWithRoleInfo
  {
    public UserWithRoleInfo()
    {
      UserRoles = new List<RoleInfo>();
    }

    public string UserId { set; get; }
    public string UserName { set; get; }
    public string UserEmail { set; get; }

    public IList<RoleInfo> UserRoles { set; get; }
  }

  public class RoleInfo
  {
    public string RoleName { set; get; }
    public bool IsInThisRole { set; get; }
  }


  // ここから Controller のコード
  public class RolesController : Controller
  {
    private ApplicationUserManager _userManager;
    private ApplicationRoleManager _roleManager;

    public ApplicationUserManager UserManager
    {
      get
      {
        return _userManager ?? 
            HttpContext.GetOwinContext().
            GetUserManager<ApplicationUserManager>();
      }
      private set
      {
        _userManager = value;
      }
    }

    public ApplicationRoleManager RoleManager
    {
      get
      {
        return _roleManager ?? 
            HttpContext.GetOwinContext().
            Get<ApplicationRoleManager>();
      }
      private set
      {
        _roleManager = value;
      }
    }

    // GET: Roles（登録済みロールの一覧）
    // Model は ApplicationRole
    public ActionResult Index()
    {
      var roles = 
        RoleManager.Roles.OrderBy(role => role.Name);
      return View(roles);
    }

    // GET: Roles/Details/Id（指定 Id のロール詳細）
    // 上の一覧以上の情報は含まれないので不要かも・・・
    // Model は ApplicationRole
    public async Task<ActionResult> Details(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                        HttpStatusCode.BadRequest);
      }

      var target = await RoleManager.FindByIdAsync(id);
      if (target == null)
      {
        return HttpNotFound();
      }
      return View(target);
    }

    // GET: Roles/Create（新規ロール作成・登録）
    // Model は上に定義した RoleModel クラス
    public ActionResult Create()
    {
      return View();
    }

    // POST: Roles/Create（新規ロール作成・登録）
    // Model は上に定義した RoleModel クラス
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> Create(RoleModel model)
    {
      if (ModelState.IsValid)
      {
        // ユーザーが入力したロール名を model.Role から取得し
        // て ApplicationRole　を生成
        var role = new ApplicationRole { Name = model.Role };

        //　上の ApplicationRole から新規ロールを作成・登録
        var result = await RoleManager.CreateAsync(role);

        if (result.Succeeded)
        {
          // 登録に成功したら Roles/Index にリダイレクト
          return RedirectToAction("Index", "Roles");
        }

        // result.Succeeded が false の場合 ModelSate にエ
        // ラー情報を追加しないとエラーメッセージが出ない。
        // AccountController と同様に AddErrors メソッドを
        // 定義して利用（一番下に定義あり）
        AddErrors(result);
      }

      // ロールの登録に失敗した場合、登録画面を再描画
      return View(model);
    }

    // GET: Roles/Edit/Ed（指定 Id のロール情報の更新）
    // ここで更新できるのはロール名のみ
    // Model は上に定義した RoleModel クラス
    public async Task<ActionResult> Edit(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                            HttpStatusCode.BadRequest);
      }

      var target = await RoleManager.FindByIdAsync(id);

      if (target == null)
      {
        return HttpNotFound();
      }

      RoleModel model = new RoleModel() { Role = target.Name };

      return View(model);
    }

    // POST: Roles/Edit/Id（指定 Id のロール情報の更新）
    // ここで更新できるのはロール名のみ
    // Model は上に定義した RoleModel クラス
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> 
                        Edit(string id, RoleModel model)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                            HttpStatusCode.BadRequest);
      }

      if (ModelState.IsValid)
      {
        var target = await RoleManager.FindByIdAsync(id);

        // ユーザーが入力したロール名を model.Role から取得し
        // て ApplicationRole の Name を書き換え
        target.Name = model.Role;

        // Name を書き換えた ApplicationRole で更新をかける
        var result = await RoleManager.UpdateAsync(target);

        if (result.Succeeded)
        {
          // 更新に成功したら Roles/Index にリダイレクト
          return RedirectToAction("Index", "Roles");
        }

        // result.Succeeded が false の場合 ModelSate にエ
        // ラー情報を追加しないとエラーメッセージが出ない。
        AddErrors(result);
      }

      // 更新に失敗した場合、編集画面を再描画
      return View(model);
    }

    // GET: Roles/Delete/Id（指定 Id のロールを削除）
    // 階層更新が行われているようで、ユーザーがアサインされて
    // いるロールも削除可能。
    // Model は ApplicationRole
    public async Task<ActionResult> Delete(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                            HttpStatusCode.BadRequest);
      }

      var target = await RoleManager.FindByIdAsync(id);

      if (target == null)
      {
        return HttpNotFound();
      }

      return View(target);
    }

    // POST: Roles/Delete/Id（指定 Id のロールを削除）
    // Model は ApplicationRole
    // 上の Delete(string id) と同シグネチャのメソッド
    // は定義できないので、メソッド名を変えて、下のよう
    // に ActionName("Delete") を設定する
    [HttpPost, ActionName("Delete")]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> 
                        DeleteConfirmed(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                            HttpStatusCode.BadRequest);
      }

      var target = await RoleManager.FindByIdAsync(id);

      if (target == null)
      {
        return HttpNotFound();
      }

      // ユーザーがアサインされているロールも以下の一行で
      // 削除可能。内部で階層更新が行われているらしい。
      var result = await RoleManager.DeleteAsync(target);

      if (result.Succeeded)
      {
        // 削除に成功したら Roles/Index にリダイレクト
        return RedirectToAction("Index", "Roles");
      }

      // result.Succeeded が false の場合 ModelSate にエ
      // ラー情報を追加しないとエラーメッセージが出ない。
      AddErrors(result);

      // 削除に失敗した場合、削除画面を再描画
      return View(target);
    }


    // 以下は:
    // (1) UserWithRoles で、上の画像のように、登録済みユーザー
    //     の一覧と各ユーザーへのロールのアサイン状況を表示し、
    // (2) Edit ボタンクリックで EditRoleAssignment に遷移し、
    //     当該ユーザーへのロールのアサインを編集して保存する
    // ・・・ためのもの。

    // GET: Roles/UserWithRoles
    // ユーザー一覧と各ユーザーにアサインされているロールを表示
    // Model は上に定義した UserWithRoleInfo クラス
    public async Task<ActionResult> UserWithRoles()
    {
      var model = new List<UserWithRoleInfo>();

      // ToList() を付与してここで DB からデータを取得して
      // DataReader を閉じておかないと、下の IsInRole メソッド
      // でエラーになるので注意
      var users = UserManager.Users.
                  OrderBy(user => user.UserName).ToList();
      var roles = RoleManager.Roles.
                  OrderBy(role => role.Name).ToList();
            
      foreach (ApplicationUser user in users)
      {
        UserWithRoleInfo info = new UserWithRoleInfo();
        info.UserId = user.Id;
        info.UserName = user.UserName;
        info.UserEmail = user.Email;

        foreach (ApplicationRole role in roles)
        {
          RoleInfo roleInfo = new RoleInfo();
          roleInfo.RoleName = role.Name;
          roleInfo.IsInThisRole = await
              UserManager.IsInRoleAsync(user.Id, role.Name);
          info.UserRoles.Add(roleInfo);
        }
        model.Add(info);
      }

      return View(model);
    }

    // GET: Roles/EditRoleAssignment/Id
    // 指定 Id のユーザーのロールへのアサインの編集
    // Model は上に定義した UserWithRoleInfo クラス
    public async Task<ActionResult> 
                        EditRoleAssignment(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                            HttpStatusCode.BadRequest);
      }

      var user = await UserManager.FindByIdAsync(id);

      if (user == null)
      {
        return HttpNotFound();
      }

      UserWithRoleInfo model = new UserWithRoleInfo();
      model.UserId = user.Id;
      model.UserName = user.UserName;
      model.UserEmail = user.Email;

      // ToList() を付与しておかないと下の IsInRole メソッド
      // で　DataReader が閉じてないというエラーになる
      var roles = RoleManager.Roles.
                  OrderBy(role => role.Name).ToList();

      foreach (ApplicationRole role in roles)
      {
        RoleInfo roleInfo = new RoleInfo();
        roleInfo.RoleName = role.Name;
        roleInfo.IsInThisRole = await
            UserManager.IsInRoleAsync(user.Id, role.Name);
        model.UserRoles.Add(roleInfo);
      }

      return View(model);
    }

    // GET: Roles/EditRoleAssignment/Id
    // 指定 Id のユーザーのロールへのアサインの編集
    // Model は上に定義した UserWithRoleInfo クラス
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> 
      EditRoleAssignment(string id, UserWithRoleInfo model)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                            HttpStatusCode.BadRequest);
      }

      if (ModelState.IsValid)
      {
        IdentityResult result;

        foreach (RoleInfo roleInfo in model.UserRoles)
        {
          // id のユーザーが roleInfo.RoleName のロールに属して
          // いるか否か。以下でその情報が必要。
          bool isInRole = await 
            UserManager.IsInRoleAsync(id, roleInfo.RoleName);

          // roleInfo.IsInThisRole には編集画面でロールのチェッ
          // クボックスのチェック結果が格納されている
          if (roleInfo.IsInThisRole)
          {
            // チェックが入っていた場合

            // 既にロールにアサイン済みのユーザーを AddToRole
            // するとエラーになるので以下の判定が必要
            if (isInRole == false)
            {
              result = await UserManager.
                       AddToRoleAsync(id, roleInfo.RoleName);
              if (!result.Succeeded)
              {
                AddErrors(result);
                return View(model);
              }
            }
          }
          else
          {
            // チェックが入っていなかった場合

            // ロールにアサインされてないユーザーを
            // RemoveFromRole するとエラーになるので以下の
            // 判定が必要
            if (isInRole == true)
            {
              result = await UserManager.
                       RemoveFromRoleAsync(id, roleInfo.RoleName);
              if (!result.Succeeded)
              {
                AddErrors(result);
                return View(model);
              }
            }
          }                    
        }

        // 編集に成功したら Roles/UserWithRoles にリダイレクト
        return RedirectToAction("UserWithRoles", "Roles");
      }

      // 編集に失敗した場合、編集画面を再描画
      return View(model);
    }

    protected override void Dispose(bool disposing)
    {
      if (disposing)
      {
        if (_userManager != null)
        {
          _userManager.Dispose();
          _userManager = null;
        }

        if (_roleManager != null)
        {
          _roleManager.Dispose();
          _roleManager = null;
        }
      }

      base.Dispose(disposing);
    }

    // ModelSate にエラー情報を追加するためのヘルパメソッド
    private void AddErrors(IdentityResult result)
    {
      foreach (var error in result.Errors)
      {
        ModelState.AddModelError("", error);
      }
    }
  }
}

MSDN ライブラリの UserManager<TUser> クラス、RoleManager<TRole, TKey> クラスの説明には非同期版メソッドしか書いてないのでそれらを使っていますが、同期版も拡張メソッドとして定義されているようです。ケースバイケースでどちらが適切かを考えて使い分けた方が良いかもしれません。

View はコントローラをベースにスキャフォールディング機能を利用して自動生成できます。Visual Studio でアクションメソッドのコードを右クリックして［ビューを追加(D)...］を選ぶと、そのためのダイアログが表示されます。

アクションメソッド EditRoleAssignment に対応する View は自動生成されるコードだけでは不十分でいろいろ追加・修正が必要です。以下にその完成版のコードを載せておきます。

@model Mcv5App2.Controllers.UserWithRoleInfo

@{
  ViewBag.Title = "EditRoleAssignment";
  Layout = "~/Views/Shared/_Layout.cshtml";
}

<h2>EditRoleAssignment</h2>


@using (Html.BeginForm())
{
  @Html.AntiForgeryToken()
    
  <h4>UserWithRoleInfo</h4>
  <hr />
  @Html.ValidationSummary("",new { @class="text-danger" })
  <table class="table">
    <tr>
      <th>
        @Html.DisplayNameFor(model => model.UserName)
      </th>
    @foreach (var role in Model.UserRoles)
    {
      <th>
        @Html.DisplayFor(modelItem => role.RoleName)
      </th>
    }
    </tr>
            
    <tr>
      <td>
        @Html.DisplayFor(model => model.UserName)
        @Html.HiddenFor(model => model.UserName)
        @Html.HiddenFor(model => model.UserEmail)
        @Html.HiddenFor(model => model.UserId)
      </td>
    @for (int i = 0; i < Model.UserRoles.Count; i++)
    {
      <td>
        @Html.EditorFor(model =>
                     model.UserRoles[i].IsInThisRole)
        @Html.HiddenFor(model => 
                     model.UserRoles[i].RoleName)
      </td>
    }
                    
    </tr>
  </table>
  <div class="form-group">
    <div class="col-md-offset-2 col-md-10">
      <input type="submit" value="Save" 
             class="btn btn-default" />
    </div>
  </div>
}

<div>
  @Html.ActionLink("Back to List", "UserWithRoles")
</div>

@section Scripts {
  @Scripts.Render("~/bundles/jqueryval")
}

上の View のコードで注意すべき点は、コレクション（上の例では Model.UserRoles で取���できる RoleInfo クラスのコレクション） についてはレンダリングされる html 要素の name 属性が連番のインデックスを含むようにすることです。具体的には、name="prefix[index].Property" というパターンにします。

そうしないとモデルバインディングがうまくいきません。その理由など詳しくは先の記事「コレクションのデータアノテーション検証」を見てください。

ASP.NET Identity ベースのフォーム認証を実装した ASP.NET MVC5 アプリケーションで、管理者がユーザー情報の追加、変更、削除を行う機能を実装する例を書きます。

CodeZine の記事「ASP.NET Identity でユーザーを管理する」に、ASP.NET Web Forms アプリ用のユーザー管理画面を作る手順が載っていますが、その MVC 版です。

ベースとなるのは、Visual Studio 2015 Community で MVC のテンプレートを利用し、認証に「個別のユーザーアカウント」を指定して自動生成させたプロジェクトです。設定は以下の画像を見てください。

上の設定で自動生成されたプロジェクトは ASP.NET Identity ベースのフォーム認証を使用する ASP.NET MVC5 アプリケーションの基本的機能を持ちます。

プロジェクトの作成後、Visual Studio で［デバッグの開始(S)］または［デバッグなしで開始(H)］で実行すると、Web サーバーとして IIS Express が立ち上がって web アプリが実行され、テンプレートに含まれている Home/Index がブラウザ（デフォルトで IE）に表示されます。

そこから［Register］をクリックしてユーザー登録を行うと、初回に EF Code First と LocalDB の機能を利用してユーザー情報のストア（.mdf ファイル）が App_Data フォルダに生成され、その後は登録した Email とパスワードでログイン可能になります。

その状態から、Web アプリケーションに管理者がユーザー情報の追加、変更、削除を行う機能を実装します。

ユーザー情報の追加、変更、削除を行うのに用いるクラスは以下の通りです。いずれもテンプレートから自動生成されたコードに完全な形で含まれているので、それらをそのまま利用します。

(1) Models/IdentityModels.cs

• IdentityUser クラスを継承した ApplicationUser クラス
• IdentityDbContext<TUser> クラスを継承した ApplicationDbContext クラス

(2) App_Start/IdentityConfig.cs

• UserManager<TUser> クラスを継承した ApplicationUserManager クラス

また、App_Start/Startup.Auth.cs の Startup クラスで、ApplicationUserManager のインスタンスを OwinContext へ登録するコードも自動生成されます。

なので、Controller では HttpContext.GetOwinContext() で OwinContext を取得し、それから GetUserManager<ApplicationUserManager>() メソッドで ApplicationUserManager オブジェクトを取得できるようになっています。

それらを利用してユーザー情報の追加、変更、削除を行う Controller の実装例を以下に示します。説明はコード内のコメントに書きましたので、それを見てください。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

// 上は自動生成されたもの。それに以下の名前空間を追加
using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.Owin;
using Mcv5App2.Models;
using System.Threading.Tasks;
using System.Net;
using System.ComponentModel.DataAnnotations;

namespace Mcv5App2.Controllers
{
  // Edit 用に AccountViewModels.cs の既存の RegisterViewModel
  // を流用しようとしたが、パスワードを入力しない場合は検証に
  // 引っかかっるので、以下の EditViewModel を定義して利用。
  // (Controller 内に定義したのは単に分けるのが面倒だから)
  public class EditViewModel
  {
    [Required]
    [EmailAddress]
    [Display(Name = "Email")]
    public string Email { get; set; }

    // PasswordValidator を使えばここでの検証は不要
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [System.ComponentModel.DataAnnotations.Compare(
     "Password", 
     ErrorMessage = 
     "Password と Confirm Password が一致しません")]
    public string ConfirmPassword { get; set; }
  }


  // ここから Controller のコード
  public class UsersController : Controller
  {
    private ApplicationUserManager _userManager;

    public ApplicationUserManager UserManager
    {
      get
      {
        return _userManager ?? 
            HttpContext.GetOwinContext().
            GetUserManager<ApplicationUserManager>();
      }
      private set
      {
        _userManager = value;
      }
    }

    // GET: Users（登録済みユーザーの一覧）
    // Model は ApplicationUser
    public ActionResult Index()
    {
      var users = UserManager.Users.
                OrderBy(user => user.UserName);
      return View(users);
    }

    // GET: Users/Details/Id（指定 Id のユーザー詳細）
    // Model は ApplicationUser
    public async Task<ActionResult> Details(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                        HttpStatusCode.BadRequest);
      }

      var target = await UserManager.FindByIdAsync(id);

      if (target == null)
      {
        return HttpNotFound();
      }

      return View(target);
    }

    // GET: Users/Create（新規ユーザー作成・登録）
    // Model は AccountViewModels.cs の RegisterViewModel
    public ActionResult Create()
    {
      return View();
    }

    // POST: Users/Create（新規ユーザー作成・登録）
    // Model は AccountViewModels.cs の RegisterViewModel
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> 
                        Create(RegisterViewModel model)
    {
      // PasswordValidator による判定の結果は ModelState
      // には反映されないので注意（下記 result で判定）
      if (ModelState.IsValid)
      {
        // ユーザー入力のメールアドレスを UserName, Email
        // プロパティに設定して ApplicationUser を生成
        var user = new ApplicationUser {
                            UserName = model.Email,
                            Email = model.Email };

        // 上の ApplicationUser とユーザー入力のパスワ
        // ードで新規ユーザーを作成・登録
        var result = await UserManager.
                     CreateAsync(user, model.Password);

        // ユーザー作成・登録の成否を result.Succeeded で
        // 判定。PasswordValidator の判定結果も result に
        // 反映される
        if (result.Succeeded)
        {
          // 登録に成功したら Users/Index にリダイレクト
          return RedirectToAction("Index", "Users");
        }
        // result.Succeeded が false の場合 ModelSate にエ
        // ラー情報を追加しないとエラーメッセージが出ない。
        // AccountController と同様に AddErrors メソッドを
        // 定義して利用（一番下に定義あり）
        AddErrors(result);
      }

      // ユーザー登録に失敗した場合、登録画面を再描画
      return View(model);
    }

    // GET: Users/Edit/Id（指定 Id のユーザー情報の更新）
    // ここで更新できるのは UserName, Email, パスワード
    // のみ。
    // Model は上に定義した EditViewModel
    public async Task<ActionResult> Edit(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                        HttpStatusCode.BadRequest);
      }

      var target = await UserManager.FindByIdAsync(id);

      if (target == null)
      {
        return HttpNotFound();
      }

      EditViewModel model = 
        new EditViewModel() { Email = target.Email };

      return View(model);
    }

    // POST: Users/Edit/Id（指定 Id のユーザー情報の更新）
    // ここで更新できるのは UserName, Email, パスワード
    // のみ。
    // UserName をソルトに使っていてパスワードだけもしくは
    // UserName だけを更新するのは NG かと思っていたが問題
    // なかった。（実際どのように対処しているかは不明）
    // Model は上に定義した EditViewModel
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> 
                  Edit(string id, EditViewModel model)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                        HttpStatusCode.BadRequest);
      }

      if (ModelState.IsValid)
      {
        var target = await UserManager.FindByIdAsync(id);
        target.Email = model.Email;
        target.UserName = model.Email;

        // ユーザーが新パスワードを入力した場合はパス
        // ワードも更新する
        if (!string.IsNullOrEmpty(model.Password))
        {
          // PasswordValidator による検証
          var resultPassword = 
              await UserManager.PasswordValidator.
                    ValidateAsync(model.Password);

          if (resultPassword.Succeeded)
          {
            // 検証 OK の場合、入力パスワードを hash
            var hashedPassword = 
                UserManager.PasswordHasher.
                HashPassword(model.Password);
            target.PasswordHash = hashedPassword;
          }
          else
          {
            // 検証 NG の場合 ModelSate にエラー情報を
            // 追加して編集画面を再描画
            AddErrors(resultPassword);
            return View(model);
          }
        }

        var resultUpdate = 
          await UserManager.UpdateAsync(target);

        if (resultUpdate.Succeeded)
        {
          // 更新に成功したら Users/Index にリダイレクト
          return RedirectToAction("Index", "Users");
        }
        AddErrors(resultUpdate);
      }

      // 更新に失敗した場合、編集画面を再描画
      return View(model);
    }

    // GET: Users/Delete/Id（指定 Id のユーザーを削除）
    // 階層更新が行われているようで、ロールがアサインされて
    // いるユーザーも削除可能。
    // Model は ApplicationUser
    public async Task<ActionResult> Delete(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                        HttpStatusCode.BadRequest);
      }

      var target = await UserManager.FindByIdAsync(id);

      if (target == null)
      {
        return HttpNotFound();
      }

      return View(target);
    }

    // POST: Users/Delete/Id（指定 Id のユーザーを削除）
    // Model は ApplicationUser
    // 上の Delete(string id) と同シグネチャのメソッド
    // は定義できないので、メソッド名を変えて、下のよう
    // に ActionName("Delete") を設定する
    [HttpPost, ActionName("Delete")]
    [ValidateAntiForgeryToken]
    public async Task<ActionResult> 
                        DeleteConfirmed(string id)
    {
      if (id == null)
      {
        return new HttpStatusCodeResult(
                        HttpStatusCode.BadRequest);
      }

      var target = await UserManager.FindByIdAsync(id);

      if (target == null)
      {
        return HttpNotFound();
      }

      // ロールがアサインされているユーザーも以下の一行で
      // 削除可能。内部で階層更新が行われているらしい。
      var result = await UserManager.DeleteAsync(target);

      if (result.Succeeded)
      {
        // 削除に成功したら Users/Index にリダイレクト
        return RedirectToAction("Index", "Users");
      }
      AddErrors(result);

      return View(target);
    }

    protected override void Dispose(bool disposing)
    {
      if (disposing)
      {
        if (_userManager != null)
        {
          _userManager.Dispose();
          _userManager = null;
        }
      }

      base.Dispose(disposing);
    }

    // ModelSate にエラー情報を追加するためのヘルパメソッド
    private void AddErrors(IdentityResult result)
    {
      foreach (var error in result.Errors)
      {
        ModelState.AddModelError("", error);
      }
    }
  }
}

上のコードは MSDN ライブラリに書いてある非同期版のメソッドを使っていますが、同期版も拡張メソッドとして定義されているようです。ケースバイケースでどちらが適切かを考えて使い分けた方が良いかもしれません。

View はコントローラをベースにスキャフォールディング機能を利用して自動生成できます。Visual Studio でアクションメソッドのコードを右クリックして［ビューを追加(D)...］を選ぶと、以下の画像のダイアログが表示されます。

ここで Template と Model class を設定して［Add］ボタンをクリックすれば View は自動生成されます。

Data context class は必ず空白にしてください。余計な設定をすると余計なコードが自動生成されて "Multiple object sets per type are not supported." というエラーになると思います。