ASP.NET應用并沒有對如何定義授權策略做硬性規定，所以我們完全根據用戶具有的任意特性（如性別、年齡、學歷、所在地區、宗教信仰、政治面貌等）來判斷其是否具有獲取目標資源或者執行目標操作的權限，但是針對角色的授權策略依然是最常用的。角色（或者用戶組）實際上就是對一組權限集的描述，將一個用戶添加到某個角色之中就是為了將對應的權限賦予該用戶。在《使用最簡潔的代碼實現登錄、認證和注銷》中，我們提供了一個用來演示登錄、認證和注銷的程序，現在我們在此基礎上添加基于“角色授權的部分”。（本文提供的示例演示已經同步到《ASP.NET Core 6框架揭秘-實例演示版》）

(資料圖)

[S2801]基于“要求”的授權[S2802]基于“策略”的授權[S2803]將“角色”綁定到路由終結點[S2804]將“授權策略”綁定到路由終結點

[S2801]基于“要求”的授權

我們提供的演示實例提供了IAccountService和IPageRenderer兩個服務，前者用用來進行校驗密鑰，后者用來呈現主頁和登錄頁面。為了在認證的時候一并將用戶擁有的角色提取出來，我們按照如下的方式為IAccountService接口的Validate方法添加了表示角色列表的輸出參數。對于實現類AccountService提供的三個賬號來說，只有“Bar”擁有一個名為“Admin”的角色。

public interface IAccountService{    bool Validate(string userName, string password, out string[] roles);}public class AccountService : IAccountService{    private readonly Dictionary _accounts = new(StringComparer.OrdinalIgnoreCase)    {        { "Foo", "password" },        { "Bar", "password" },        { "Baz", "password" }    };    private readonly Dictionary _roles = new(StringComparer.OrdinalIgnoreCase)    {            { "Bar", new string[]{"Admin" } }    };    public bool Validate(string userName, string password, out string[] roles)    {        if (_accounts.TryGetValue(userName, out var pwd) && pwd == password)        {            roles = _roles.TryGetValue(userName, out var value) ? value : Array.Empty();            return true;        }        roles = Array.Empty();        return false;    }}

我們假設演示的應用是供擁有“Admin”角色的管理人員使用的，所以只能擁有該角色的用戶才能訪問應用的主頁，未授權訪問會自動定向到我們提供的“訪問拒絕”頁面。我們在另一個IPageRenderer服務接口中添加了如下這個RenderAccessDeniedPage方法，并在PageRenderer類型中完成了對應的實現。

public interface IPageRenderer{    IResult RenderLoginPage(string? userName = null, string? password = null, string? errorMessage = null);    IResult RenderAccessDeniedPage(string userName);    IResult RenderHomePage(string userName);}public class PageRenderer : IPageRenderer{    public IResult RenderAccessDeniedPage(string userName)    {        var html = @$"                
{userName}, your access is denied.
        Change another account    ";        return Results.Content(html, "text/html");    }    ...}

在現有的演示程序基礎上，我們不需要作太大的修改。由于需要引用授權功能，我們調用了IServiceCollection接口的AddAuthorization擴展方法注冊了必要的服務。由于引入了“訪問決絕”頁面，我們注冊了對應的終結點，該終結點依然采用標準的路徑“Account/AccessDenied”，對應的處理方法DenyAccess直接調用上面這個RenderAccessDeniedPage方法將該頁面呈現出來。

using App;using Microsoft.AspNetCore.Authentication;using Microsoft.AspNetCore.Authentication.Cookies;using Microsoft.AspNetCore.Authorization;using Microsoft.AspNetCore.Authorization.Infrastructure;using System.Security.Claims;using System.Security.Principal;var builder = WebApplication.CreateBuilder();builder.Services    .AddSingleton()    .AddSingleton()    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie();builder.Services.AddAuthorization();var app = builder.Build();app.UseAuthentication();app.Map("/", WelcomeAsync);app.MapGet("Account/Login", Login);app.MapPost("Account/Login", SignInAsync);app.Map("Account/Logout", SignOutAsync);app.Map("Account/AccessDenied", DenyAccess);app.Run();Task WelcomeAsync(HttpContext context, ClaimsPrincipal user, IPageRenderer renderer, IAuthorizationService authorizationService);IResult Login(IPageRenderer renderer);Task SignInAsync(HttpContext context, HttpRequest request, IPageRenderer renderer,IAccountService accountService);Task SignOutAsync(HttpContext context);IResult DenyAccess(ClaimsPrincipal user, IPageRenderer renderer) => renderer.RenderAccessDeniedPage(user?.Identity?.Name!);

我們需要對用來認證請求的SignInAsync方法作相應的修改。如下的代碼片段所示，對于成功通過認證的用戶，我們會為它創建一個ClaimsPrincipal對象來表示當前用戶。這個對象也是授權的目標對象，授權的本質就是確定該對象是否攜帶了授權資源或者操作所要求的“資質”。由于我們采用的是基于“角色”的授權，所以我們將該用于擁有的角色以“聲明（Claim）”的形式添加到表示身份的ClaimsIdentity對象上。

Task SignInAsync(HttpContext context, HttpRequest request, IPageRenderer renderer,IAccountService accountService){    var username = request.Form["username"];    if (string.IsNullOrEmpty(username))    {        return renderer.RenderLoginPage(null, null, "Please enter user name.").ExecuteAsync(context);    }    var password = request.Form["password"];    if (string.IsNullOrEmpty(password))    {        return renderer.RenderLoginPage(username, null, "Please enter user password.").ExecuteAsync(context);    }    if (!accountService.Validate(username, password, out var roles))    {        return renderer.RenderLoginPage(username, null, "Invalid user name or password.").ExecuteAsync(context);    }    var identity = new GenericIdentity(name: username, type: CookieAuthenticationDefaults.AuthenticationScheme);    foreach (var role in roles)    {        identity.AddClaim(new Claim(ClaimTypes.Role, role));    }var user = new ClaimsPrincipal(identity);    return context.SignInAsync(user);}

演示實例授權的效果就是讓擁有“Admin”角色的用戶才能訪問主頁，所以我們將授權實現在如下這個WelcomeAsync方法中。如果當前用戶（由注入的ClaimsPrincipal對象表示）并未通過認證，我們依然調用HttpContext上下文的ChallengeAsync擴展方法返回一個“匿名請求”的質詢。在確定用戶通過認證的前提下，我們創建了一個RolesAuthorizationRequirement來表示主頁針對授權用戶的“角色要求”。授權檢驗通過調用注入的IAuthorizationService對象的AuthorizeAsync方法來完成，我們將代表當前用戶的ClaimsPrincipal對象和包含RolesAuthorizationRequirement對象的數組作為參數。如果授權成功，主頁得以正常呈現，否則我們調用HttpContext上下文的ForbidAsync擴展方法返回“權限不足”的質詢，上面提供的“拒絕訪問”頁面將會呈現出來。

async Task WelcomeAsync(HttpContext context, ClaimsPrincipal user, IPageRenderer renderer,IAuthorizationService authorizationService){    if (user?.Identity?.IsAuthenticated ?? false)    {        var requirement = new RolesAuthorizationRequirement(new string[] { "admin" });        var result = await authorizationService.AuthorizeAsync(            user:user, resource: null,            requirements: new IAuthorizationRequirement[] { requirement });        if (result.Succeeded)        {            await renderer.RenderHomePage(user.Identity.Name!).ExecuteAsync(context);        }        else        {            await context.ForbidAsync();        }    }    else    {      await  context.ChallengeAsync();    }}

程序啟動之后，具有“Admin”權限的“Bar”用戶能夠正常主頁，其他的用戶（比如“Foo”）會自動重定向到“訪問拒絕”頁面，具體效果體現在圖1中。

圖1　針對主頁的授權

[S2802]基于“策略”的授權

我們調用IAuthorizationService服務的AuthorizeAsync方法進行授權檢驗的時候，實際上是將授權要求定義在一個RolesAuthorizationRequirement對象中，這是一種比較煩瑣的編程方式。另一種推薦的做法是在應用啟動的過程中創建一系列通過AuthorizationPolicy對象表示的授權規則，并指定一個唯一的名稱對它們進行全局注冊，那么后續就可以針對注冊的策略名稱進行授權檢驗。如下面的代碼片段所示，在調用AddAuthorization擴展方法注冊授權相關服務時，我們利用作為輸入參數的Action對象對授權策略進行了全局注冊。表示授權規策略的AuthorizationPolicy對象實際上是對基于角色“Admin”的RolesAuthorizationRequirement對象的封裝，我們調用AuthorizationOptions配置選項的AddPolicy方法對授權策略進行注冊，并將注冊名稱設置為“Home”。

using App;using Microsoft.AspNetCore.Authentication;using Microsoft.AspNetCore.Authentication.Cookies;using Microsoft.AspNetCore.Authorization;using Microsoft.AspNetCore.Authorization.Infrastructure;using System.Security.Claims;using System.Security.Principal;var builder = WebApplication.CreateBuilder();builder.Services    .AddSingleton()    .AddSingleton()    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie();builder.Services.AddAuthorization(AddAuthorizationPolicy);var app = builder.Build();app.UseAuthentication();app.Map("/", WelcomeAsync);app.MapGet("Account/Login", Login);app.MapPost("Account/Login", SignInAsync);app.Map("Account/Logout", SignOutAsync);app.Map("Account/AccessDenied", DenyAccess);app.Run();void AddAuthorizationPolicy(AuthorizationOptions options){    var requirement = new RolesAuthorizationRequirement(new string[] { "admin" });    var requirements = new IAuthorizationRequirement[] { requirement };    var policy = new AuthorizationPolicy(requirements: requirements, authenticationSchemes: Array.Empty());    options.AddPolicy("Home", policy);}

在呈現主頁的WelcomeAsync方法中，我們依然調用IAuthorizationService服務的AuthorizeAsync方法來檢驗用戶是否具有對應的權限，但這次采用的是另一個可以直接指定授權策略注冊名稱的AuthorizeAsync方法重載（S2802）。

async Task WelcomeAsync(HttpContext context, ClaimsPrincipal user, IPageRenderer renderer,    IAuthorizationService authorizationService){    if (user?.Identity?.IsAuthenticated ?? false)    {        var result = await authorizationService.AuthorizeAsync(user: user, policyName: "Home");if (result.Succeeded)        {            await renderer.RenderHomePage(user.Identity.Name!).ExecuteAsync(context);        }        else        {            await context.ForbidAsync();        }    }    else    {      await  context.ChallengeAsync();    }}

[S2803]將“角色”綁定到路由終結點

上面演示的例子都調用IAuthorizationService對象的AuthorizeAsync方法來確定指定的用戶是否滿足提供的授權規則，實際上針對請求的授權直接交給AuthorizationMiddleware中間件來完成，該中間件可以采用如下的方式調用UseAuthorization擴展方法進行注冊。

...var builder = WebApplication.CreateBuilder();builder.Services    .AddSingleton()    .AddSingleton()    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie();builder.Services.AddAuthorization();var app = builder.Build();app    .UseAuthentication()    .UseAuthorization();...

當該中間件在進行授權檢驗的時候，會從當前終結點的元數據中提取授權規則，所以我們在注冊對應終結點的時候需要提供對應的授權規則。由于WelcomeAsync方法不再需要自行完成授權檢驗，所以它只需要將主頁呈現出來就可以了。針對“Admin”角色的授權要求直接利用標注在該方法上的AuthorizeAttribute特性來指定，該特性就是為AuthorizationMiddleware中間件提供授權規則的元數據（S2803）。

[Authorize(Roles ="admin")]IResult WelcomeAsync(ClaimsPrincipal user, IPageRenderer renderer)=> renderer.RenderHomePage(user.Identity!.Name!);

[S2804]將“授權策略”綁定到路由終結點

如果在調用AddAuthorization擴展方法時已經定義了授權策略，我們也可以按照如下的方式將策略名稱設置為AuthorizeAttribute特性大的Policy屬性（S2804）。

[Authorize(Policy = "Home")]IResult WelcomeAsync(ClaimsPrincipal user, IPageRenderer renderer) => renderer.RenderHomePage(user.Identity!.Name!);

如果采用Lambda表達式來定義終結點處理器，我們可以按照如下的方式將AuthorizeAttribute特性標注在表達式上。注冊終結點的各種Map方法會返回一個IEndpointConventionBuilder對象，我們可以安裝如下的方式調用它的RequireAuthorization擴展方法將AuthorizeAttribute特性作為一個IAuthorizeData對象添加到注冊終結點的元數據集合。RequireAuthorization擴展方法來有一個將授權策略名稱作為參數的重載。

app.Map("/",[Authorize(Roles ="admin")]ClaimsPrincipal user, IPageRenderer renderer)    => renderer.RenderHomePage(user.Identity!.Name!));app.Map("/",[Authorize(Policy = "Home")](ClaimsPrincipal user, IPageRenderer renderer)    => renderer.RenderHomePage(user.Identity!.Name!));app.Map("/", WelcomeAsync).RequireAuthorization(new AuthorizeAttribute {  Roles = "Admin"});app.Map("/", WelcomeAsync).RequireAuthorization(new AuthorizeAttribute {  Policy = "Home"});app.Map("/", WelcomeAsync).RequireAuthorization(policyNames: "Home");

關鍵詞：