asp.net core 3.x 授權默認流程

一、前言

接上一篇《asp.net core 3.x 授權中的概念》，本篇看看asp.net core默認授權的流程，從兩個方面來看整個授權系統是怎么運行的：啟動階段的配置、請求階段中間件的處理流程，

由于asp.net core 3.x目前使用終結點路由，因此授權框架可以用于所有asp.net web專案型別，比如：webapi mvc razorpages...，但本篇只以MVC為例

二、核心概念關系圖

三、啟動階段的配置

主要體現為3點

1. 注冊相關服務
2. 配置授權選項物件AuthorizationOptions
3. 注冊授權中間件

3.1、注冊相關服務和選項配置

在mvc專案Startup.ConfigreServices中services.AddControllersWithViews(); （MvcServiceCollectionExtensions）用來向依賴注入框架注冊各種mvc相關服務，其中會呼叫services.AddAuthorization(選項)擴展方法（PolicyServiceCollectionExtensions）注冊授權相關服務，此擴展方法內部還會呼叫兩個擴展方法，這里不再深入，

這里主要需要搞懂2個問題：

1. 方法傳入的選項
2. 具體注冊了哪些服務

3.1.1、授權選項AuthorizationOptions

AddAuthorization擴展方法的引數是Action<AuthorizationOptions>型別的，這是asp.net core中典型的選項模型，將來某個地方需要時，直接注入此選項物件，那時依賴注入容器會使用此委托對這個選項物件賦值，所以我們在啟動時可以通過此物件來對授權框架進行配置，

最最重要的是我們可以在這里配置全域授權策略串列，參考上圖的右側中間部分，原始碼不多，注意注釋，

 1 //代表授權系統的全域選項物件，里面最最核心的就是存盤著全域授權策略
 2 public class AuthorizationOptions
 3 {
 4     //存盤全域授權策略（AuthorizationPolicy），key是策略唯一名，方便將來獲取
 5     private IDictionary<string, AuthorizationPolicy> PolicyMap { get; } = new Dictionary<string, AuthorizationPolicy>(StringComparer.OrdinalIgnoreCase);
 6     //授權驗證時，將遍歷所有授權處理器（Authorization）逐個進行驗證，若某個發生錯誤是否立即終止后續的授權處理器的執行
 7     public bool InvokeHandlersAfterFailure { get; set; } = true;
 8     //默認授權策略，拒絕匿名訪問
 9     public AuthorizationPolicy DefaultPolicy { get; set; } = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();
10     //若將來授權檢查時沒有找到合適的授權策略，默認授權策略也是空的情況下會回退使用此策略
11     public AuthorizationPolicy FallbackPolicy { get; set; }
12     //添加全域策略
13     public void AddPolicy(string name, AuthorizationPolicy policy)
14     {
15         if (name == null)
16         {
17             throw new ArgumentNullException(nameof(name));
18         }
19 
20         if (policy == null)
21         {
22             throw new ArgumentNullException(nameof(policy));
23         }
24 
25         PolicyMap[name] = policy;
26     }
27     //添加全域策略，同時可以對此策略進行配置
28     public void AddPolicy(string name, Action<AuthorizationPolicyBuilder> configurePolicy)
29     {
30         if (name == null)
31         {
32             throw new ArgumentNullException(nameof(name));
33         }
34 
35         if (configurePolicy == null)
36         {
37             throw new ArgumentNullException(nameof(configurePolicy));
38         }
39 
40         var policyBuilder = new AuthorizationPolicyBuilder();
41         configurePolicy(policyBuilder);
42         PolicyMap[name] = policyBuilder.Build();
43     }
44     //獲取指定名稱的策略
45     public AuthorizationPolicy GetPolicy(string name)
46     {
47         if (name == null)
48         {
49             throw new ArgumentNullException(nameof(name));
50         }
51 
52         return PolicyMap.ContainsKey(name) ? PolicyMap[name] : null;
53     }
54 }

舉個栗子：

 1 services.AddControllersWithViews();
 2 services.AddRazorPages();
 3 services.AddAuthorization(opt =>
 4 {
 5     opt.AddPolicy("授權策略1", builer => {
 6         builer.RequireRole("admin", "manager");
 7         builer.AddAuthenticationSchemes("cookie", "google");
 8         //繼續配置....
 9     });
10     opt.AddPolicy("授權策略2", builer => {
11         builer.RequireRole("teacher");
12         builer.AddAuthenticationSchemes("wechat", "qq");
13         //繼續配置....
14     });
15 });

3.1.2、具體注冊了哪些服務：

• 策略評估器IPolicyEvaluator：名字有點詭異，默認實作PolicyEvaluator，授權中間件委托它來實作身份驗證和授權處理，它內部會呼叫AuthorizationService，進而執行所有授權處理器AuthorizationHandler
• 授權服務IAuthorizationService：上一篇有說，不詳述了，默認實作DefaultAuthorizationService，除了授權中間件會呼叫它來進行授權處理，我們業務代碼中也可以呼叫它來做授權驗證，比如：針對資源的特殊授權
• 授權策略提供器IAuthorizationPolicyProvider：默認實作DefaultAuthorizationPolicyProvider，可以通過它來獲取指定名稱的授權，它就是從全域授權策略串列里去找，也就是上面說的AuthorizationOptions中
• 授權處理器提供器IAuthorizationHandlerProvider：默認實作DefaultAuthorizationHandlerProvider，通過它來獲取系統中所有的授權處理器，其實就是從IOC容器中獲取
• 授權評估器IAuthorizationEvaluator：默認實作DefaultAuthorizationEvaluator，授權處理器AuthorizationHandler在執行完授權后，結果是存盤在AuthorizationHandlerContext中的，這里的評估器只是根據AuthorizationHandlerContext創建一個授權結果AuthorizationResult，給了我們一個機會來加入自己的代碼而已
• 授權處理器背景關系物件的工廠IAuthorizationHandlerContextFactory：默認實作DefaultAuthorizationHandlerContextFactory，授權處理器AuthorizationHandler在授權時需要傳入AuthorizationHandlerContext（上面說了授權完成后的結果也存盤在里面），所以在執行授權處理器之前需要構建這個背景關系物件，就是通過這個工廠構建的，主要的資料來源就是 當前 或者  指定的  授權策略AuthorizationPolicy
• 授權處理器IAuthorizationHandler：默認實作PassThroughAuthorizationHandler，授權的主要邏輯在授權處理器中定義，授權服務在做授權時會遍歷系統所有的授權處理器逐一驗證，而驗證往往需要用到授權依據，PassThroughAuthorizationHandler比較特殊，它會看授權依據是否已經實作了IAuthorizationHandler，如過是，則直接把授權依據作為授權處理器進行執行，因為多數情況下一個授權處理器型別是專門針對某種授權依據定義的，

這些介面都是擴展點，就問你怕不怕？當然絕大部分時候我們不用管，默認的就足夠用了，

3.2、注冊授權中間件

主要注意的位置的為題，必須在路由和身份驗證之后，

1 app.UseRouting();
2 app.UseAuthentication();
3 app.UseAuthorization();

擴展方法內部注冊了AuthorizationMiddleware

四、請求階段的處理流程

如果你對mvc稍有經驗，就曉得在一個Action上使用[Authorize]就可以實施授權，現在我們假設我們在默認mvc專案中的HomeController定義如下Action，并應用授權標簽

1         [Authorize(Policy = "p1")]//使用全域授權策略中的"p1"進行授權判斷
2         [Authorize(AuthenticationSchemes = "google")]//只允許使用google身份驗證登錄的用戶訪問
3         [Authorize(Roles = "manager")]//只允許角色為manager的訪問
4         public IActionResult Privacy()
5         {
6             return View();
7         }

4.1、授權中間件AuthorizationMiddleware

核心步驟如下：

1. 從當前請求拿到終結點
2. 通過終結點拿到其關聯的IAuthorizeData集合
3. 呼叫AuthorizationPolicy.CombineAsync根據IAuthorizeData集合創建一個復合型策略，此策略就是本次用來做授權檢查的策略，也就是文章中多次提到的當前這略
4. 從IOC容器中獲取策略評估器對上面得到的策略進行身份驗證，多種身份驗證得到的用戶證件資訊會合并進HttpContext.User
5. 若Action上應用了IAllowAnonymous，則放棄授權檢查（為毛不早點做這步？）
6. 通過策略評估器對策略進行授權檢查，注意這里的引數，傳入身份驗證評估結果和將終結點作為資源
7. 若授權評估要求質詢，則遍歷策略所有的身份驗證方案，進行質詢，若策略里木有身份驗證方案則使用默認身份驗證方案進行質詢
8. 若授權評估拒絕就直接呼叫身份驗證方案進行拒絕

步驟1、2得益于asp.net core 3.x的終結點路由，我們可以在進入MVC框架前就拿到Action及其之上應用的各種Atrribute，從而得到我們對當前授權策略定制所需要的資料

步驟3會根據得到IAuthorizeData集合（AuthorizeAttribute實作了IAuthorizeData，它不再是一個過濾器）創建當前準備用來做授權的策略，授權策略中 “身份驗證方案串列” 和 “授權依據串列”，就是通過這里的標簽來的，具體來說：

• [Authorize(Policy = "p1")]：會通過“p1”去全域授權策略（AuthorizationOptions物件中）拿到對應的策略，然后與當前策略合并，也就是把“p1”策略中的身份驗證方案串列、授權依據串列與當前策略合并，
• [Authorize(AuthenticationSchemes = "google")]：用來定制當前策略的“身份驗證方案串列”，當然最終和上面說的合并，
• [Authorize(Roles = "manager")]：會創建一個RolesAuthorizationRequirement型別的授權依據加入到當前策略中

這些Attribute可以應用多次，最終都是來定制當前授權策略的，后續步驟都會依賴此授權策略，

步驟4中，若發現本次授權策略中定義了多個身份驗證方案，則會注意進行身份驗證，得到的多張證件會合并到當前用戶HttpContext.User中，當然默認身份驗證得到的用戶資訊也在其中，

上面步驟4、6是委托策略評估器PolicyEvaluator來完成的，往下看..

4.2、策略評估器PolicyEvaluator

核心任務就兩個，身份驗證、進行授權

4.2.1、AuthenticateAsync

若策略沒有設定AuthenticationSchemes，則只判斷下當前請求是否已做身份驗證，若做了就回傳成功
若策略設定了AuthenticationSchemes，則遍歷身份驗證方案逐個進行身份驗證處理 context.AuthenticateAsync(scheme); ，將所有得到的用戶標識重組成一個復合的用戶標識，

4.2.2、AuthorizeAsync

呼叫IAuthorizationService進行權限判斷，若成功則回傳成功，
否則     若身份驗證通過則 PolicyAuthorizationResult.Forbid() 直接通知身份驗證方案，做拒絕訪問處理；否則回傳質詢

所以授權檢查的任務又交給了授權服務AuthorizationService

4.3、授權服務AuthorizationService

核心步驟如下：

1. 通過IAuthorizationHandlerContextFactory創建AuthorizationHandlerContext，此背景關系包含：授權依據（來源與當前授權策略） 當前用戶（httpContext.User）和資源（當前終結點）
2. 遍歷所有授權處理器AuthorizationHandler，這些授權處理器是通過IAuthorizationHandlerProvider獲取的，默認情況下是從IOC容器中獲取的，逐個呼叫每個授權處理器執行授權檢查
3. 所有授權處理器執行驗證后的結果還是存盤在上面說的這個背景關系物件AuthorizationHandlerContext中，回呼授權評估器IAuthorizationEvaluator將這個背景關系物件轉換為授權結果AuthorizationResult

步驟2還會判斷AuthorizationOptios.InvokeHandlersAfterFailure，來決定當某個處理器發生錯誤時，是否停止執行后續的授權處理器，

4.4、授權處理器AuthorizationHandler

前面講過，默認只注冊了一個PassThroughAuthorizationHandler授權處理器，它會遍歷當前授權策略中實作了IAuthorizationHandler的授權依據（意思說這些物件既是授權處理器，也是授權依據），直接執行它們，

public class PassThroughAuthorizationHandler : IAuthorizationHandler
{
    public async Task HandleAsync(AuthorizationHandlerContext context)
    {
        foreach (var handler in context.Requirements.OfType<IAuthorizationHandler>())
        {
            await handler.HandleAsync(context);
        }
    }
}

以基于角色的授權依據RolesAuthorizationRequirement為例，它繼承于AuthorizationHandler<RolesAuthorizationRequirement>，且實作IAuthorizationRequirement

 1 public class RolesAuthorizationRequirement : AuthorizationHandler<RolesAuthorizationRequirement>, IAuthorizationRequirement
 2 {
 3     //省略部分代碼...
 4     public IEnumerable<string> AllowedRoles { get; }
 5     protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, RolesAuthorizationRequirement requirement)
 6     {
 7         if (context.User != null)
 8         {
 9             bool found = false;
10             if (requirement.AllowedRoles == null || !requirement.AllowedRoles.Any())
11             {
12                 // Review: What do we want to do here?  No roles requested is auto success?
13             }
14             else
15             {
16                 found = requirement.AllowedRoles.Any(r => context.User.IsInRole(r));
17             }
18             if (found)
19             {
20                 context.Succeed(requirement);
21             }
22         }
23         return Task.CompletedTask;
24     }
25 }

五、最后

可以感受到asp.net core 3.x目前的權限設計棒棒噠，默認的處理方式已經能滿足大部分需求，即使有特殊需求擴展起來也非常簡單，前面注冊部分看到注冊了各種服務，且都有默認實作，這些服務在授權檢查的不同階段被使用，如果有必要我們可以自定義實作某些介面來實作擴展，本篇按默認流程走了一波，最好先看前一篇，這時候再去看官方檔案或原始碼應該更容易，日常開發使用其實參考官方檔案就足夠了，無非就是功能權限和資料權限，看情況也許不會寫后續的應用或擴展篇了，

標籤：.NET Core

上一篇：ASP.NET Core ResponseCache進行快取操作

下一篇：給微軟的依賴注入框架寫一些擴展方法