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中典型的選項模型，將來某個地方需要時，直接注入此選項對象，那時依賴注入容器會使用此委託對這個選項對象賦值。所以我們在啟動時可以通過此對象來對授權框架進行配置。

最最重要的是我們可以在這裡配置全局授權策略列表，參考上圖的右側中間部分，源碼不多，注意注釋。

//代表授權系統的全局選項對象，裡面最最核心的就是存儲著全局授權策略  public class AuthorizationOptions  {      //存儲全局授權策略（AuthorizationPolicy），key是策略唯一名，方便將來獲取      private IDictionary<string, AuthorizationPolicy> PolicyMap { get; } = new Dictionary<string, AuthorizationPolicy>(StringComparer.OrdinalIgnoreCase);      //授權驗證時，將遍歷所有授權處理器（Authorization）逐個進行驗證，若某個發生錯誤是否立即終止後續的授權處理器的執行      public bool InvokeHandlersAfterFailure { get; set; } = true;      //默認授權策略，拒絕匿名訪問      public AuthorizationPolicy DefaultPolicy { get; set; } = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();      //若將來授權檢查時沒有找到合適的授權策略，默認授權策略也是空的情況下會回退使用此策略      public AuthorizationPolicy FallbackPolicy { get; set; }      //添加全局策略      public void AddPolicy(string name, AuthorizationPolicy policy)      {          if (name == null)          {              throw new ArgumentNullException(nameof(name));          }            if (policy == null)          {              throw new ArgumentNullException(nameof(policy));          }            PolicyMap[name] = policy;      }      //添加全局策略，同時可以對此策略進行配置      public void AddPolicy(string name, Action<AuthorizationPolicyBuilder> configurePolicy)      {          if (name == null)          {              throw new ArgumentNullException(nameof(name));          }            if (configurePolicy == null)          {              throw new ArgumentNullException(nameof(configurePolicy));          }            var policyBuilder = new AuthorizationPolicyBuilder();          configurePolicy(policyBuilder);          PolicyMap[name] = policyBuilder.Build();      }      //獲取指定名稱的策略      public AuthorizationPolicy GetPolicy(string name)      {          if (name == null)          {              throw new ArgumentNullException(nameof(name));          }            return PolicyMap.ContainsKey(name) ? PolicyMap[name] : null;      }  }    AuthorizationOptions

舉個栗子： 

services.AddControllersWithViews();  services.AddRazorPages();  services.AddAuthorization(opt =>  {      opt.AddPolicy("授權策略1", builer => {          builer.RequireRole("admin", "manager");          builer.AddAuthenticationSchemes("cookie", "google");          //繼續配置....      });      opt.AddPolicy("授權策略2", builer => {          builer.RequireRole("teacher");          builer.AddAuthenticationSchemes("wechat", "qq");          //繼續配置....      });  });

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，並應用授權標籤

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

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

public class RolesAuthorizationRequirement : AuthorizationHandler<RolesAuthorizationRequirement>, IAuthorizationRequirement  {      //省略部分程式碼...      public IEnumerable<string> AllowedRoles { get; }      protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, RolesAuthorizationRequirement requirement)      {          if (context.User != null)          {              bool found = false;              if (requirement.AllowedRoles == null || !requirement.AllowedRoles.Any())              {                  // Review: What do we want to do here?  No roles requested is auto success?              }              else              {                  found = requirement.AllowedRoles.Any(r => context.User.IsInRole(r));              }              if (found)              {                  context.Succeed(requirement);              }          }          return Task.CompletedTask;      }  }

五、最後

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

VirMach 便宜 VPS

QNews

QNews