آموزش هوش تجاری از ۰ تا ۱۰۰

پس از احراز هویت، ASP.NET Core Web API باید مجوز دسترسی را صادر کند. این فرآیند به یک میکروسرویس اجازه می‌دهد تا API‌ها را برای برخی از کاربران احراز هویت شده، اما نه برای همه، در دسترس قرار دهد. مجوز می‌تواند بر اساس نقش‌های کاربران یا بر اساس خط‌مشی سفارشی انجام شود، که ممکن است شامل بازرسی ادعاها یا سایر روش‌های اکتشافی باشد.

محدود کردن دسترسی به یک مسیر ASP.NET Core MVC به آسانی اعمال یک ویژگی Authorize در متد اقدام (یا در کلاس کنترلر اگر همه اقدامات کنترل کننده نیاز به مجوز دارند) است، همانطور که در مثال زیر نشان داده شده است:

public class AccountController : Controller
{
    public ActionResult Login()
    {
    }

    [Authorize]
    public ActionResult Logout()
    {
    }
}

به طور پیش‌فرض، افزودن یک ویژگی Authorize بدون پارامتر، دسترسی به کاربران تأیید شده برای آن کنترل‌کننده یا عملکرد را محدود می‌کند. برای محدود کردن بیشتر یک API برای در دسترس بودن فقط برای کاربران خاص، ویژگی را می توان گسترش داد تا نقش ها یا خط مشی های مورد نیازی را که کاربران باید رعایت کنند، مشخص کند.

اجرای مجوز مبتنی بر نقش
ASP.NET Core Identity یک مفهوم داخلی از نقش ها دارد. علاوه بر کاربران، ASP.NET Core Identity اطلاعات مربوط به نقش‌های مختلف مورد استفاده توسط برنامه را ذخیره می‌کند و کاربرانی که به کدام نقش‌ها اختصاص داده شده‌اند را پیگیری می‌کند. این تخصیص‌ها را می‌توان به صورت برنامه‌ریزی با نوع RoleManager که نقش‌ها را در ذخیره‌سازی ماندگار به‌روزرسانی می‌کند، و نوع UserManager که می‌تواند نقش‌ها را به کاربران اعطا یا لغو کند، تغییر داد.

اگر با توکن‌های حامل JWT احراز هویت می‌کنید، میان‌افزار احراز هویت حامل ASP.NET Core JWT، نقش‌های کاربر را بر اساس ادعاهای نقش موجود در توکن پر می‌کند. برای محدود کردن دسترسی به یک کنش یا کنترلر MVC به کاربران در نقش‌های خاص، می‌توانید یک پارامتر Roles را در حاشیه‌نویسی (ویژگی) Authorize قرار دهید، همانطور که در قطعه کد زیر نشان داده شده است:

[Authorize(Roles = "Administrator, PowerUser")]
public class ControlPanelController : Controller
{
    public ActionResult SetTime()
    {
    }

    [Authorize(Roles = "Administrator")]
    public ActionResult ShutDown()
    {
    }
}

در این مثال، فقط کاربران در نقش‌های Administrator یا PowerUser می‌توانند به APIها در کنترل‌کننده ControlPanel (مانند اجرای اکشن SetTime) دسترسی داشته باشند. ShutDown API محدودتر است تا فقط به کاربرانی که در نقش Administrator هستند دسترسی داشته باشند.

برای اینکه یک کاربر در چندین نقش باشد، از چندین ویژگی Authorize استفاده می کنید، همانطور که در مثال زیر نشان داده شده است:

[Authorize(Roles = "Administrator, PowerUser")]
[Authorize(Roles = "RemoteEmployee ")]
[Authorize(Policy = "CustomPolicy")]
public ActionResult API1 ()
{
}

در این مثال، برای فراخوانی API1، کاربر باید:

• در نقش Administrator یا PowerUser باشید و
• در نقش RemoteEmployee باشید و
• رضایت یک کنترل کننده سفارشی برای مجوز CustomPolicy.

اجرای مجوز مبتنی بر سیاست
قوانین مجوز سفارشی را می توان با استفاده از سیاست های مجوز نیز نوشت. این بخش یک نمای کلی ارائه می دهد. برای اطلاعات بیشتر، به کارگاه مجوز ASP.NET مراجعه کنید.

خط مشی های مجوز سفارشی در روش Startup.ConfigureServices با استفاده از روش service.AddAuthorization ثبت می شوند. این متد یک نماینده می گیرد که آرگومان AuthorizationOptions را پیکربندی می کند.

services.AddAuthorization(options =>
{
    options.AddPolicy("AdministratorsOnly", policy =>
        policy.RequireRole("Administrator"));

    options.AddPolicy("EmployeesOnly", policy =>
        policy.RequireClaim("EmployeeNumber"));

    options.AddPolicy("Over21", policy =>
        policy.Requirements.Add(new MinimumAgeRequirement(21)));
});

همانطور که در مثال نشان داده شده است، سیاست ها می توانند با انواع مختلفی از الزامات مرتبط باشند. پس از ثبت نام خط‌مشی‌ها، می‌توان آن‌ها را با ارسال نام خط‌مشی به‌عنوان آرگومان Policy از ویژگی Authorize، روی یک کنش یا کنترل‌کننده اعمال کرد (برای مثال، [Authorize(Policy="EmployeesOnly")] سیاست‌ها می‌توانند الزامات متعددی داشته باشند، نه فقط یکی (همانطور که در این مثال ها نشان داده شده است).

در مثال قبلی، اولین تماس AddPolicy فقط یک راه جایگزین برای مجوز دادن بر اساس نقش است. اگر [Authorize(Policy="AdministratorsOnly")] روی یک API اعمال شود، فقط کاربرانی که در نقش سرپرست هستند می توانند به آن دسترسی داشته باشند.

دومین فراخوان AddPolicy راه آسانی را نشان می‌دهد که یک ادعای خاص باید برای کاربر وجود داشته باشد. روش RequireClaim همچنین به صورت اختیاری مقادیر مورد انتظار را برای ادعا می گیرد. اگر مقادیر مشخص شده باشند، الزام تنها در صورتی برآورده می شود که کاربر هم ادعای نوع صحیح و هم یکی از مقادیر مشخص شده را داشته باشد. اگر از میان افزار احراز هویت حامل JWT استفاده می کنید، همه ویژگی های JWT به عنوان ادعای کاربر در دسترس خواهند بود.

جالب ترین سیاست نشان داده شده در اینجا در روش سوم AddPolicy است، زیرا از یک نیاز مجوز سفارشی استفاده می کند. با استفاده از الزامات مجوز سفارشی، می توانید کنترل زیادی بر نحوه اجرای مجوز داشته باشید. برای انجام این کار، باید این انواع را پیاده سازی کنید:

• یک نوع Requirements که از IAuthorizationRequirement مشتق شده و حاوی فیلدهایی است که جزئیات مورد نیاز را مشخص می کند. در مثال، این یک فیلد سنی برای نوع نمونه MinimumAgeRequirement است.
• کنترل‌کننده‌ای که AuthorizationHandler<TRequirement> را پیاده‌سازی می‌کند، که در آن T نوعی از IAuthorizationRequirement است که کنترل‌کننده می‌تواند برآورده کند. کنترل‌کننده باید متد HandleRequirementAsync را پیاده‌سازی کند، که بررسی می‌کند آیا یک زمینه مشخص که حاوی اطلاعاتی درباره کاربر است، نیاز را برآورده می‌کند یا خیر.

اگر کاربر الزامات را برآورده کند، یک فراخوانی به context.Succeed نشان می دهد که کاربر مجاز است. اگر چندین راه وجود داشته باشد که یک کاربر ممکن است یک نیاز مجوز را برآورده کند، می توان چندین کنترل کننده ایجاد کرد.

علاوه بر ثبت الزامات خط‌مشی سفارشی با تماس‌های AddPolicy، شما همچنین باید کنترل‌کننده‌های نیازمندی‌های سفارشی را از طریق Dependency Injection ثبت کنید (services.AddTransient<IAuthorizationHandler, MinimumAgeHandler>()).