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點
- 註冊相關服務
- 配置授權選項物件AuthorizationOptions
- 註冊授權中介軟體
3.1、註冊相關服務和選項配置
在mvc專案Startup.ConfigreServices中services.AddControllersWithViews(); （MvcServiceCollectionExtensions）用來向依賴注入框架註冊各種mvc相關服務。其中會呼叫services.AddAuthorization(選項)擴充套件方法（PolicyServiceCollectionExtensions）註冊授權相關服務，此擴充套件方法內部還會呼叫兩個擴充套件方法，這裡不再深入。
這裡主要需要搞懂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 });
View Code
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
核心步驟如下：
- 從當前請求拿到終結點
- 通過終結點拿到其關聯的IAuthorizeData集合
- 呼叫AuthorizationPolicy.CombineAsync根據IAuthorizeData集合建立一個複合型策略，此策略就是本次用來做授權檢查的策略，也就是文章中多次提到的當前這略
- 從IOC容器中獲取策略評估器對上面得到的策略進行身份驗證，多種身份驗證得到的使用者證件資訊會合並進HttpContext.User
- 若Action上應用了IAllowAnonymous，則放棄授權檢查（為毛不早點做這步？）
- 通過策略評估器對策略進行授權檢查，注意這裡的引數，傳入身份驗證評估結果和將終結點作為資源
- 若授權評估要求質詢，則遍歷策略所有的身份驗證方案，進行質詢，若策略裡木有身份驗證方案則使用預設身份驗證方案進行質詢
- 若授權評估拒絕就直接呼叫身份驗證方案進行拒絕
步驟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
核心步驟如下：
- 通過IAuthorizationHandlerContextFactory建立AuthorizationHandlerContext，此上下文包含：授權依據（來源與當前授權策略） 當前使用者（httpContext.User）和資源（當前終結點）
- 遍歷所有授權處理器AuthorizationHandler，這些授權處理器是通過IAuthorizationHandlerProvider獲取的，預設情況下是從IOC容器中獲取的。逐個呼叫每個授權處理器執行授權檢查
- 所有授權處理器執行驗證後的結果還是儲存在上面說的這個上下文物件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目前的許可權設計棒棒噠，預設的處理方式已經能滿足大部分需求，即使有特殊需求擴充套件起來也非常簡單，前面註冊部分看到註冊了各種服務，且都有預設實現，這些服務在授權檢查的不同階段被使用，如果有必要我們可以自定義實現某些介面來實現擴充套件。本篇按預設流程走了一波，最好先看前一篇。這時候再去看官方文件或原始碼應該更容易。日常開發使用其實參考官方文件就足夠了，無非就是功能許可權和資料許可權，看情況也許不會寫後續的應用或擴充套件篇