نحوه استفاده از ASP.NET MVC Identity

استفاده از ASP.NET MVC Identity

در این فصل به شما نشان خواهم داد که چگونه برای اختیار دهی به کاربر و احراز هویت کاربرانی که در فصل قبل ایجاد کردیم از ASP.NET Identity استفاده کنید. همچنین توضیح خواهم داد که چگونه پلتفرم ASP.NET بنیان درخواست های احراز هویت را فراهم می کند و در نهایت به این موضوع خواهیم پرداخت که چگونه ASP.NET Identity جهت احراز هویت کاربران برای این بنیان مناسب بوده و چگونه می تواند از طرق نقش ها، اختیار دهی به کاربر را اجبار کند. در جدول زیر این فصل به صورت خلاصه بیان شده است.

آماده کردن پروژه ی نمونه

در این فصل کار بر روی پروژه ی Users را که در فصل 13 آغاز کردیم را ادامه می دهیم. هیچ نیازی به تغییر دادن مولفه های نرم افزار وجود ندارد.

احراز هویت کاربران

اصلی ترین کارکرد ASP.NET Identity ، احراز هویت کاربران است، به همین دلیل در این بخش قصد دارم به چگونگی انجام این کار بپردازم. در جدول زیر احراز هویت به زبان ساده بیان شده است.

درک بهتر فرایند احراز هویت کاربر و اختیار دهی به آن

سیستم ASP.NET Identity در پلتفرم ASP.NET یکپارچه شده است، این یعنی برای کنترل دسترسی به action method ها مانند Authorize attribute تنها استفاده از تکنیک های استاندارد فریمورک MVC کفایت می کند. در این بخش می خواهم در Home controller محدودیت های اولیه ای را بر روی متد Index action اعمال کنم و پس از آن ویژگی هایی را پیاده سازی کنم که کاربران بتوانند هویت خودشان را محرز کنند و به Home controller دسترسی پیدا کنند.

using System.Web.Mvc;
using System.Collections.Generic; namespace Users.Controllers {
    public class HomeController : Controller {
        [Authorize]
        public ActionResult Index() { Dictionary< string, object > data
        = new Dictionary< string, object >(); data.Add("Placeholder", "Placeholder"); return View(data);
        }
    }
}

استفاده از Authorize attribute به این صورت عمومی ترین فرم اختیار دهی به کاربر و محدود کردن دسترسی action method ها به درخواست هایی است که توسط کاربرانی که توسط نرم افزار احراز هویت شده اند ایجاد می شوند. اگر نرم افزار را اجرا کنید و آدرس URL ای را درخواست کنید که Index action را در Home controller (/Home/Index ، /Home یا تنها / ) مورد هدف قرار دهد ، در این صورت خطاهای نشان داده شده در شکل زیر را مشاهده خواهید کرد.

پلتفرم ASP.NET از طریق شیء HttpContext اطلاعات مفیدی در رابطه با کاربر را ارائه می کند. این شیء جهت بررسی وضعیت درخواست موجود و تعیین محرز شدن یا نشدن هویت کاربر توسط Authorize attribute مورد استفاده قرار می گیرد. مشخصه HttpContext.User ، پیاده سازی رابط Iprincipalinter را برگشت می دهد. این رابط در System.Security.Principal namespace تعریف می شود. رابط Iprincipal مشخصه و متد نشان داده شده در جدول زیر را تعریف می کند.

پیاده سازی رابط Iidentity که توسط مشخصه ی IPrincipal.Identity برگشت داده می شود از طریق مشخصاتی که در جدول زیر نشان داده ام برخی از اطلاعات اولیه و در عین حال مفید در رابطه با کاربر موجود را ارائه می کند.

ASP.NET Identity شامل ماژول ای است که وظیفه ی آن مدیریت رخداد چرخه ی عمر AuthenticateRequest ( به این رویداد در فصل 3 پرداخته ام) است همچنین این ماژول جهت مشخص کردن محرز بودن یا نبودن هویت کاربر از cookie های ارسال شده توسط مرورگر استفاده می کند.
تا اندکی دیگر به شما نشان خواهم داد که این کوکی ها چگونه ایجاد می شوند. اگر هویت کاربر احراز شود، ماژول فریمورک ASP.NET مقدار مشخصه ی IIdentity.IsAuthenticated را بر روی true قرار می دهد، در غیر این صورت مقدار آن را بر روی false تنظیم می کند. (هنوز به پیاده سازی ویژگی هایی که به کاربر امکان احراز هویت را بدهد نرسیده ایم، در این فرایند مقدار مشخصه ی IsAuthenticated همیشه در این نرم افزار فرضی false است. )
ماژول Authorize ، مقدار مشخصه ی IsAuthenticated را چک می کند و اگر متوجه شود که هویت کاربر محرز نشده است، کد وضعیت حاصل را بر روی 401 قرار داده و درخواست را منسوخ می کند. در این لحظه ماژول ASP.NET Identity درخواست را قطع کرده و کاربر را به سمت آدرس URL /Account/Login هدایت می کند. این آدرس، همان آدرسی است که من در کلاس IdentityConfig تعریف کرده ام و در فصل 13 به عنوان کلاس OWIN startup آن را مشخص کرده ام (مانند زیر)

using Microsoft.AspNet.Identity; using Microsoft.Owin;
using Microsoft.Owin.Security.Cookies; using Owin;
using Users.Infrastructure;
namespace Users {
    public class IdentityConfig {
        public void Configuration(IAppBuilder app) { app.CreatePerOwinContext< AppUserManager >(AppUserManager.Create);
        app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, LoginPath = new PathString("/Account/Login"),
            });
        }
    }
}

مرورگر آدرس /Account/Login را درخواست می کند اما با توجه به اینکه این آدرس با هیچ controller یا action ای در این نمونه پروژه تناظر ندارد، سرور خطای 404 (Not Found) را برگشت داده و در نهایت باعث خطای نشان داده شده در شکل 1-14 می شود.

آماده شدن برای پیاده سازی احراز هویت

هرچند که این درخواست منتهی به پیام خطا شد، اما درخواست داده شده در بخش قبل نشان می دهد که چگونه ASP.NET Identity برای چرخه عمر درخواست استاندارد ASP.NET ساخته شده و برای آن مناسب است. گام بعد پیاده سازی controller ای است که کار آن دریافت درخواست های آدرس /Account/Login و احراز هویت کاربر است. همانطور که در قطعه کد زیر مشخص است، من کار خودم را با اضافه کردن کلاس مدل جدیدی به فایل UserViewModels.cs آغاز کرده ام.

Using System.ComponentModel.DataAnnotations; namespace Users.Models {
    public class CreateModel { [Required]
        public string Name { get; set; }
        [Required]
        public string Email { get; set; }
        [Required]
        public string Password { get; set; }
    }
    public class LoginModel {
        [Required]
        public string Name { get; set; }
        [Required]
        public string Password { get; set; }
    }
}

این مدل جدید دارای مشخصه های نام و رمز عبور است. هر دوی این مشخصات توسط اتریبیوت Required نشان شده اند تا بتوانم ارائه شدن مقادیر توسط کاربر را بررسی کنم.

همانطور که در قطعه کد زیر مشاهده می کنید، برای گردآوری و پردازش اطلاعات محرمانه ی کاربر یک account controller را به همراه Login action method هایی به پروژه اضافه کرده ام. با توجه به اینکه قرار است view را تعریف کنم و با دقت فرایند ارزیابی اطلاعات محرمانه کاربر و sign in کردن کاربران به نرم افزار را انجام دهم، منطق احراز هویت (authentication logic ) را در این تیتر پیاده سازی نکرده ام.

using System.Threading.Tasks; using System.Web.Mvc;
using Users.Models;
namespace Users.Controllers {
    [Authorize]
    public class AccountController : Controller {
        [AllowAnonymous]
        public ActionResult Login(string returnUrl) {
            if (ModelState.IsValid) {}
            ViewBag.returnUrl = returnUrl; return View();
        }
    [HttpPost]
    [AllowAnonymous]
    [ValidateAntiForgeryToken]
        public async Task< ActionResult > Login(LoginModel details, string returnUrl) { return View(details);
        }
    }
}

هر چند که این فایل هنوز هویت کاربران را احراز نمی کند، اما Account controller شامل برخی از زیرساخت های مفیدی است که می خواهم جدای از کد ASP.NET Identity به آن بپردازم. کد ASP.NET Identity را تا اندکی دیگر به متد Login action اضافه خواهم کرد.
اولا، توجه داشته باشید که هر دو نسخه ی متد Login action دارای آرگومانی به نام returnUrl هستند. زمانی که کاربری URL محدودی را بخواهد، هر دوی این متدها به همراه query string که مشخص می کند که کاربر بعد از محرز شدن هویت اش به چه URL ای باید پس فرستاده شود، هر دوی این متد ها به آدرس /Account/Login هدایت می شوند. اگر می خواهید این فرایند را با چشم ببینید، نرم افزار را باز کنید و آدرس /Home/Index را درخواست دهید. بعد از انجام این کار مرورگر شما مانند زیر به آدرس دیگری هدایت می شود.

/Account/Login?ReturnUrl=%2FHome%2FIndex

مقدار پارامتر رشته ی کوئری ReturnUrl این امکان را به من می دهد تا کاربر را به گونه ای به آدرس های URL هدایت کنم که حرکت بین بخش های امن و آزاد نرم افزار به صورت روان و بی نقص انجام شود.
ثانیا، به attribute هایی که بر روی Accountcontroller اعمال کرده ام توجه کنید. قابلیت Controller هایی که وظیفه ی مدیریت حساب های کاربری را برعهده دارند، تنها باید در اختیار کاربرانی قرار گیرد که هویت آن ها احراز شده باشد. از جمله این قابلیت ها می توان به ریست کردن پسورد اشاره کرد. در همین راستا من Authorizeattribute را در کلاس controller اعمال کرده ام، سپس از AllowAnonymousattribute در تک تک action method ها استفاده کرده ام. این کار باعث می شود دسترسی کاربران احراز هویت شده به صورت پیش فرض محدود شود اما این امکان برای کاربرانی که هویت آن ها هنوز احراز نشده است به وجود می آید تا به نرم افزار وارد شوند.
در نهایت، از ValidateAntiForgeryTokenattribute استفاده کرده ام. این attribute در کنار متد کمکی Html.AntiForgeryTokenhelper داخل view کار می کند و از جعل درخواست های بین وب سایت ها جلوگیری می کند. این شیوه از جعل از اطمینانی که کاربر شما به نرم افزارتان دارد سوء استفاده می کند، و استفاده از این attribute و متد کمکی بسیار مهم است.

http://en.wikipedia.org/wiki/Cross-site_request_forgery.

آخرین قدم مقدماتی من ایجاد view ای است که برای گردآوری اطلاعات محرمانه از کاربر رندر شود. در قطعه کد زیر محتوای داخل فایل Views/Account/Login.cshtml نشان داده شده است. این فایل را با راست کلیک کردن بر روی Indexaction method و انتخاب Add View از منوی باز شده ایجاد کرده ام.

@model Users.Models.LoginModel
@{ ViewBag.Title = "Login";}
< h2 >Log In< /h2 >
@Html.ValidationSummary()
 
@using (Html.BeginForm()) {
    @Html.AntiForgeryToken();
    < input type="hidden" name="returnUrl" value="@ViewBag.returnUrl" / >
    < div class="form-group" >
        < label >Name< /label >
        @Html.TextBoxFor(x = > x.Name, new { @class = "form-control" })
    < /div >
    < div class="form-group" >
        < label >Password< /label >
        @Html.PasswordFor(x = > x.Password, new { @class = "form-control" })
    < /div >
    < button class="btn btn-primary" type="submit" >Log In< /button >
}

نکات قابل توجه این view استفاده از متد کمکی Html.AntiForgeryTokenhelper و ایجاد المان input مخفی برای نگهداری آرگومان returnUrl است. از نقطه نظرهای دیگر این view صرفا یک Razor view استاندارد است. اما در عین حال مقدمات احراز هویت را تکمیل کرده و شیوه ی قطع شدن و تغییر آدرس درخواست های احراز هویت نشده را نشان می دهد. برای آنکه این controller جدید را تست کنید تنها کافیست نرم افزار را اجرا کنید و آدرس /Home/Index را درخواست کنید. بعد از انجام این کار مانند شکل زیر به آدرس /Account/Login هدایت خواهید شد.

افزودن احراز هویت کاربر

درخواست های مربوط به آدرس های URL حفاظت شده تا به اینجای کار به درستی به Accountcontroller تغییر جهت داده اند. اما اطلاعات محرمانه ی ارائه شده توسط کاربر هنوز برای احراز هویت به کار گرفته نشده اند. در قطعه کد زیر می توانید مشاهده کنید که چگونه پیاده سازی Loginaction را تکمیل کرده ام.

using System.Threading.Tasks; using System.Web.Mvc;
using Users.Models;
using Microsoft.Owin.Security; using System.Security.Claims; using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.Owin; using Users.Infrastructure;
using System.Web;
namespace Users.Controllers {
    [Authorize]
    public class AccountController : Controller {
        [AllowAnonymous]
        public ActionResult Login(string returnUrl) {
            ViewBag.returnUrl = returnUrl;
            return View();
        }
        [HttpPost]
        [AllowAnonymous]
        [ValidateAntiForgeryToken]
        public async Task< ActionResult > Login(LoginModel details, string returnUrl) { if (ModelState.IsValid) {
            AppUser user = await UserManager.FindAsync(details.Name, details.Password);
            if (user == null) {
                ModelState.AddModelError("", "Invalid name or password.");
                } else {
                ClaimsIdentity ident = await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
                AuthManager.SignOut();
                AuthManager.SignIn(new AuthenticationProperties { IsPersistent = false}, ident);
                return Redirect(returnUrl);
                }
            }
            ViewBag.returnUrl = returnUrl;
                return View(details);
        }
            private IAuthenticationManager AuthManager { get {
                return HttpContext.GetOwinContext().Authentication;
            }
        }
        private AppUserManager UserManager { get {
            return HttpContext.GetOwinContext().GetUserManager< AppUserManager >();
            }
        }
    }
}

ساده ترین بخش در اینجا ارزیابی اطلاعات محرمانه است که من این کار را از طریق متد FindAsync مربوط به کلاس AppUserManager انجام داده ام. شما این کلاس را از فصل 13 به عنوان کلاس user manager به خاطر دارید.

...
AppUser user = await UserManager.FindAsync(details.Name, details.Password);
...

با توجه به اینکه قرار است از کلاس AppUserManager در Accountcontroller به صورت مکرر استفاده کنم، مشخصه ای به نام UserManager را تعریف کرده ام. این مشخصه با استفاده از متد گسترشی GetOwinContextext برای کلاس HttpContext نمونه های کلاس AppUserManager را برگشت میدهد. در فصل 13 برای Admincontroller نیز دقیقا به همین شیوه عمل کرده ام.
متد FindAsync نام کاربری و رمز عبور کاربر را گرفته و اگر حساب کاربری وجود داشته باشد و رمز عبور صحیح وارد شده باشد نمونه ای از کلاس user (در این نمونه پروژه AppUser کلاس user است) را برگشت میدهد. اما اگر چنین حساب کاربری وجود نداشته باشد و یا رمز عبور وارد شده با رمز عبور ذخیره شده در دیتابیس مطابقت نداشته باشد، در این صورت متد FindAsync مقدار null را برگشت می دهد. در چنین حالاتی من خطایی را به model state اضافه می کنم تا به کاربر بفهماند که یک جای کار اشتباه بوده است.
اگر متد FindAsync شیء AppUser را برگشت دهد، در این صورت من باید کوکی ای را ایجاد کنم که مرورگر برای آنکه نشان دهد کاربران احراز هویت شده اند این کوکی را طی درخواست های بعدی ارسال میکند. کدهای دستوری مربوط را در زیر می توانید مشاهده کنید.

...
ClaimsIdentity ident = await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
AuthManager.SignOut();
AuthManager.SignIn(new AuthenticationProperties {IsPersistent = false}, ident); return Redirect(returnUrl);
...

اولین قدم ایجاد شیء ClaimsIdentity است تا بتوان کاربران را شناسایی کرد. کلاس ClaimsIdentity پیاده سازی ASP.NET Identity مربوط به IIdentity است که به آن در جدول زیر پرداخته ام. کاربرد این کلاس را می توانید در بخش «استفاده از نقش ها برای اختیاردهی به کاربر»در ادامه ی همین فصل مشاهده کنید.

برای ایجاد نمونه های ClaimsIdentity باید متد user manager CreateIdentityAsync فراخوانی شود و شیء user و مقداری از برشمارش DefaultAuthenticationTypes عبور داده شود. زمانی که بخواهیم با تک تک حساب های کاربری کار کنیم، مقدار ApplicationCookie می تواند مفید باشد.
مرحله ی بعد باطل کردن تمامی کوکی های احراز هویتی موجود و ایجاد کردن کوکی های جدید است. با توجه به اینکه باید به شیئی که مشخصه ی AuthManager به صورت مکرر آن را ارائه میکند دسترسی پیدا کنم، این مشخصه را همزمان با ایجاد کارایی در این فصل تعریف کرده ام. این مشخصه پیاده سازی رابط IAuthenticationManager را برگشت می دهد. این رابط وظیفه ی انجام گزینه های مرسوم احراز هویت را برعهده دارد. در جدول زیر می توانید مفیدترین متدهای ارائه شده توسط رابط IAuthenticationManager را مشاهده کنید.

آرگومان های متد SignIn شیء AuthenticationProperties هستند که این شیء وظیفه ی پیکربندی فرآیند احراز هویت و شیء ClaimsIdentity را برعهده دارد. برای آنکه کوکی احراز هویت در مرورگر ماندگار باشد، مشخصه ی IsPersistent تعریف شده توسط شیء AuthenticationProperties را بر روی true قرار داده ام. این یعنی بعد از آنکه کاربر session جدیدی را شروع کرد، دیگر نیازی به احراز هویت مجدد نداشته باشد (مشخصه های دیگری نیز هستند که توسط کلاس AuthenticationProperties تعریف می شوند، اما در حال حاضر مشخصه ی IsPersistent پرکاربردترین آنهاست).
مرحله ی آخر هدایت کردن کاربر به آدرس URL ای است که قبل از آغاز فرآیند احراز هویت درخواست داده است. این کار را توسط متد Redirect انجام میدهم.

نگاهی به احراز هویت دو مرحله ای

تا به اینجای کار در این فصل احراز هویت تک مرحله ای را انجام داده ام. طی این نوع از احراز هویت کاربر قادر است با استفاده از تنها یک بخش از اطلاعات محرمانه ی خود (رمز عبور) هویت خود را احراز کند.
ASP.NET Identity از احراز هویت دو مرحله ای نیز پشتیبانی میکند. طی این نوع از احراز هویت، کاربر به اطلاعاتی بیشتر از رمز عبور نیاز دارد. این اطلاعات معمولا در لحظه ای که کاربر می خواهد هویت خود را احراز کند، به وی داده می شود. از جمله رایج ترین مثال های مربوط به احراز هویت دو مرحله ای می توان به مقداری از یک توکن SecureID و یا یک کد احراز هویت که به صورت ایمیل یا پیامک ارسال می شود، اشاره کرد (اگر بخواهم خیلی صریح بگویم، احراز هویت دو مرحله ای هرچیزی می تواند باشد. مثل اثر انگشت، اسکن قرنیه و تشخیص صدا. هرچند که این گزینه ها در تعداد کمی از نرم افزارها رایج هستند).
با توجه به اینکه فرد هکر باید رمز عبور کاربر را بداند و به هرچیزی که مرحله ی دوم احراز هویت مانند حساب ایمیل یا تلفن همراه دسترسی داشته باشد، امنیت افزایش پیدا میکند.
به دو دلیل در این کتاب به احراز هویت دو مرحله ای نپرداخته ام. اولین دلیل این است که این شیوه از احراز هویت کارهای مقدماتی زیادی را می طلبد، مانند پیاده سازی منطق ارزیابی آن و آماده کردن زیرساختی که بتواند ایمیل ها و پیامک های مرحله ی دوم را توزیع کند. هر دوی اینها از حیطه ی این کتاب خارج هستند.
دومین دلیل این است که احراز هویت دو مرحله ای کاربر را مجبور می کند برای احراز هویت اطلاعات اضافه ای را به خاطر داشته باشد، مانند در خاطر نگه داشتن شماره تلفن و یا نگهداری یک توکن امنیتی در کنار خود. این رویکرد همیشه برای نرم افزارهای تحت وب مناسب نیست. برای من پیش آمده است که در شغل های مختلف برای بیش از 10 سال کدی امنیتی را با خود حمل میکرده ام و در بعضی مواقع به دلیل آنکه این کد را در خانه جا گذاشتم، دیگر نتوانستم به سیستم کارفرما دسترسی پیدا کنم.
اگر به امنیت دو مرحله ای علاقه مند هستید، در این صورت به شما پیشنهاد می کنم احراز هویت را به ارائه دهنده ی شخص ثالثی مانند گوگل واگذار کنید. زیرا در این صورت این حق انتخاب را دارد که از امنیت اضافی (و سخت شدن کار) ای که احراز هویت دو مرحله ای فراهم می کند استفاده بکند یا خیر. در فصل 15 به احراز هویت شخص ثالث پرداخته ام.

امتحان کردن احراز هویت

برای امتحان کردن احراز هویت کاربر، نرم افزار را اجرا کنید و آدرس /Home/Index را درخواست کنید. زمانی که به آدرس /Account/Login هدایت شدید، جزئیات یکی از کاربرانی که در ابتدای این فصل لیست کرده ام را وارد کنید ( برای مثال اسم Joe و رمز عبور MySecret). بر روی دکمه ی Log In کلیک کنید. بعد از انجام این کار مرورگر شما به همان آدرس /Home/Index هدایت می شود، اما با این تفاوت که این بار کوکی احراز هویتی که دسترسی به action method را میسر می کند submit می شود.

اختیار دهی به کاربران با استفاده از نقش ها (roles)

در بخش قبل از Authorize attribute به ساده ترین فرم استفاده کردم. این attribute این اختیار را به تمامی کاربران احراز هویت شده می داد تا action method را اجرا کنند. در این بخش چگونگی تصحیح اختیار دهی را به شما خواهم آموخت تا بتوانید به صورت دانه ریزتر به کنترل اجرای action ها توسط کاربران بپردازید. در جدول زیر اختیار دهی به زبان ساده بیان شده است.

افزودن امکان پشتیبانی از role ها

ASP.NET Identity برای دسترسی به role ها و مدیریت آن ها ، کلاسی به نام RoleManager را که اصطلاحا strongly typed است را ارائه می کند. حرف T در این کلاس پیاده سازی رابط IRole است که این رابط توسط مکانیزم ذخیره سازی داده مورد استفاده جهت نشان دادن role ها پشتیبانی می شود. Entity Framework جهت پیاده سازی رابط IRole از کلاسی به نام IdentityRole استفاده می کند. این کلاس مشخصات نشان داده شده در جدول زیر را تعریف می کند.

چندان تمایلی به leak کردن ارجاع ها به کلاس IdentityRole در هیچ یک از بخش های نرم افزارم ندارم، زیرا این کار باعث می شوند برای ذخیره سازی داده های نقش محور به Entity Framework وابسته بشوم، به همین دلیل کار خودم را با ایجاد کلاس نقش محور مختص به نرم افزاری می کنم که از IdentityRole مشتق شده است. برای تعریف کلاس نشان داده شده در قطعه کد زیر کلاس فایلی به نام AppRole.cs را در پوشه ی Models فراخوانی کرده و از آن استفاده کرده ام.

using Microsoft.AspNet.Identity.EntityFramework;

namespace Users.Models {
    public class AppRole : IdentityRole { public AppRole() : base() {}
        public AppRole(string name) : base(name) { }
    }
}

کلاس RoleManager< T > از طریق متدها و مشخصات نشان داده شده در جدول زیر بر روی نمونه های کلاس Iroleimplementation عملیات انجام می دهد.

این متدها از همان الگوی ساده ی UserManager< T > بیان شده در فصل 13 پیروی می کنند. به دنبال همین الگو جهت مدیریت کاربران، کلاسی به نام AppRoleManager.cs را به پوشه ی Infrastructure اضافه کردم و از آن برای تعریف کلاس نشان داده شده در قطعه کد زیر استفاده کردم.

using System;
using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.EntityFramework; using Microsoft.AspNet.Identity.Owin;
using Microsoft.Owin; using Users.Models;

namespace Users.Infrastructure {
    public class AppRoleManager : RoleManager< AppRole >, IDisposable { public AppRoleManager(RoleStore< AppRole > store)
    : base(store) {}

    public static AppRoleManager Create( IdentityFactoryOptions< AppRoleManager > options, IOwinContext context) {
        return new AppRoleManager(new RoleStore< AppRole >(context.Get< AppIdentityDbContext >()));
        }
    }
}

این کلاس، متد Create ای را تعریف می کند که به ازای هر یک از درخواست هایی که طی آن ها دسترسی به داده های هویتی میسر می شود، امکان نمونه سازی برای استارت کلاس OWIN فراهم می شود. این یعنی نیازی به پخش کردن چگونگی ذخیره سازی داده های نقشی در سرتاسر نرم افزار وجود ندارد.
تنها کاری که می توانم انجام دهم این است که نمونه های کلاس AppRoleManager را دریافت کنم و بر روی آن ها عملیات انجام دهم. در قطعه کد زیر می توانید مشاهده کنید که من چگونه کلاس role manager را با استارت کلاس OWIN (IdentityConfig) ثبت کرده ام. با انجام این کار می توان مطمئن شد که نمونه های کلاس AppRoleManager با استفاده از همان زمینه ی دیتابیس Entity Framework ای ایجاد می شوند که در کلاس AppUserManager کاربرد دارند.

using Microsoft.AspNet.Identity; using Microsoft.Owin;
using Microsoft.Owin.Security.Cookies; using Owin;
using Users.Infrastructure;

namespace Users {
    public class IdentityConfig {
        public void Configuration(IAppBuilder app) {

            app.CreatePerOwinContext< AppIdentityDbContext >(AppIdentityDbContext.Create); app.CreatePerOwinContext< AppUserManager >(AppUserManager.Create); app.CreatePerOwinContext< AppRoleManager >(AppRoleManager.Create);

            app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, LoginPath = new PathString("/Account/Login"),
            });
        }
    }
}

برای مطالعه سرفصل آموزش پیشرفته MVC کلیک نمایید .