Authorization، Roles، Claims و Policies

.NET 10 | Permission Model و Resource-based Authorization

Authorization پس از احراز هویت تعیین می‌کند Caller مجاز به انجام چه عملیاتی است. Role برای گروه‌بندی مناسب است، اما Claim و Policy امکان مدل دقیق‌تر Permission را فراهم می‌کنند.

این فصل با تمرکز بر قراردادهای قابل اتکا، مرزبندی مسئولیت‌ها و رفتار قابل پیش‌بینی در محیط واقعی تنظیم شده است. مثال‌ها بر پایه ASP.NET Core و .NET 10 نوشته شده‌اند.

1. چارچوب موضوع و مفاهیم اصلی

Authorization پس از احراز هویت تعیین می‌کند Caller مجاز به انجام چه عملیاتی است. Role برای گروه‌بندی مناسب است، اما Claim و Policy امکان مدل دقیق‌تر Permission را فراهم می‌کنند.

واژگان و قراردادهای این بخش باید در سراسر پروژه یکدست بمانند؛ تفاوت میان لایه HTTP، منطق برنامه و زیرساخت زمانی روشن می‌ماند که مسئولیت هر جزء به‌صورت صریح تعریف شود.

2. ساختار پیشنهادی در پروژه

Policyهای Permission در Startup تعریف می‌شوند و Endpointها با نام Policy محافظت می‌شوند. برای تصمیم وابسته به Resource از IAuthorizationService یا Handler سفارشی استفاده می‌شود.

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Products.Write", policy =>
    {
        policy.RequireAuthenticatedUser();
        policy.RequireClaim("permission", "products.write");
    });
});

[Authorize(Policy = "Products.Write")]
[HttpPost]
public IActionResult Create() => Ok();

3. سناریوی اجرایی

کاربر ممکن است Role عمومی داشته باشد اما تنها برخی Permissionها را دریافت کند. در ویرایش Resource، علاوه بر Permission عمومی می‌توان مالکیت همان Resource را نیز بررسی کرد.

در این سناریو، قرارداد ورودی و خروجی، مسیر شکست و رفتار قابل مشاهده سرویس باید پیش از جزئیات پیاده‌سازی مشخص شود. این رویکرد باعث می‌شود تغییرات بعدی بدون وابستگی پنهان و با امکان تست دقیق انجام شوند.

var result = await authorization.AuthorizeAsync(
    User,
    product,
    "CanEditProduct");

if (!result.Succeeded)
    return Forbid();

4. اصول طراحی و نگهداری

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

• Permissionها نام پایدار و Domain-based داشته باشند.
• منوی UI جای Enforcement سمت Server را نمی‌گیرد.
• Fallback Policy برای Private-by-default قابل بررسی است.
• Roleهای بسیار ریز به Permission ترجیح داده نشوند.

5. خطاهای رایج و کنترل آن‌ها

بخش مهمی از کیفیت یک API در نحوه جلوگیری از خطاهای تکرارشونده مشخص می‌شود. موارد زیر باید در بازبینی کد و تست‌های قبل از انتشار کنترل شوند.

• تکیه صرف به مخفی کردن Button در Frontend.
• برگرداندن 401 به‌جای 403 برای کاربر احراز هویت‌شده بدون مجوز.
• Hard-code Permission در نقاط پراکنده بدون Constant/Policy.
• Policyهای نامفهوم و وابسته به نام صفحه UI.

6. چک‌لیست نهایی فصل

• هر Endpoint حساس Policy مشخص دارد.
• 403 و 401 درست تفکیک می‌شوند.
• Permissionها در Backend enforce می‌شوند.
• Resource-based Authorization برای سناریوهای مالکیت پوشش داده شده است.

7. جمع‌بندی

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