前言
預計是通過三篇來將清楚asp.net core 3.x中的授權：1、基本概念介紹；2、asp.net core 3.x中授權的默認流程；3、擴展，
在完全沒有概念的情況下無論是看官方檔案還是原始碼都暈乎乎的，希望本文能幫到你，不過我也是看原始碼結合官方檔案看的，可能有些地方理解不對，所以只作為參考，
要求對asp.net core的基礎有所有了解：Host、依賴注入、日志、配置、選項模式、終結點路由、身份驗證等，還是推薦A大博客
概述
歸納來說授權就是：某人 針對某個資源 可以做什么操作，如：張三 針對銷售訂單 可以查看、審核、取消等操作
- 某人：這個好理解，只要登錄系統的用戶我們就曉得他是誰；額外的他屬于某個角色、屬于某個部門、甚至我們可以規定年齡段在18-30歲的能干什么，30-50歲的能干啥，這些都屬于所屬角色、所屬部門、所屬年齡段都是用戶的一個屬性，會作為權限判斷的一個依據
- 資源：可以任何形式的資源，比如銷售訂單、商品、等等；也可以有更復雜的規則，比如金額大于10000以上的，必須經過老總審核這種要求；另外比如一個頁面也可以看做是資源，比如是否允許誰可以訪問某個頁面，對資源的限定也將作為權限判斷的一部分
- 操作：比如上面說的查看、審核、新增、修改..巴拉巴拉...當然操作也作為權限判斷的一部分，
除了上面這3個概念外加一個權限判斷邏輯，就組成了授權系統，下面逐一介紹asp.net core 3.x中授權系統涉及到的相關概念
注：
功能權限：這是我們通常說的某人（包含所屬角色，所屬部門等）可以訪問某個選單下的某個按鈕
資料權限：上面說的訂單金額大于10000的必須要經理角色才可以審核
這個說來也沒啥區別，一個按鈕通常是對應到mvc中的某個action，所以還是可以看成是操作；金額大于10000，這個也只是對資源的一種選定
還有一種情況，說一個按鈕的點擊對應到一個action，那么這個按鈕到底是看做“操作”呢，還是把這個Action看成是一個頁面地址，作為資源呢？這個就看怎么設計了，mvc默認是當做資源，
用戶標識ClaimsPrincipal
現實生活中，一個人有多種證件，比如身份證、登機牌、就診卡等，你去到不同的機構需要出示不同的證件，而每張證件上又有不同的資訊，比如身份驗證上有身份證號、姓名、性別、出示日期等等... 登機牌上有 航班號、座位號之類的，
在asp.net core中，ClaimsPrincipal就代表上面說的這個人，它可能存在多張證件，證件用ClaimsIdentity表示，當然得有一張證件作為主要證件（如身份證）；一張證件又包含多條資訊，可以用類似字典的形式IDictionary<string,string>來存盤證件的資訊，但是字典不夠面向物件，所以單獨為證件上的一條資訊定義了一個類Claim，拿身份證上的出生日期來說，ClaimType="出生日期"，Value=https://www.cnblogs.com/firebet/p/“1995-2-4”
上面我們一直拿一個人擁有多張證件來舉例，其實并不準確，因為對系統來說并不關心是誰登錄，可能是一個用戶、也可能是一個第三方應用，所以將ClaimsPrincipal理解為一個登錄到系統的主體更合理，
在一個系統中可能同時存在多種身份驗證方案，比如我們系統本身做了用戶管理功能，使用最簡單的cookie身份驗證方案，或者使用第三方登錄，微信、QQ、支付寶賬號登錄，通常一個身份驗證方案可以產生一張證件（ClaimsIdentity），當然某個身份驗證方案也可以將獲得的Claim添加到一張現有的證件中，這個是靈活的，默認情況下，用戶登錄時asp.net core會選擇設定好的默認身份驗證方案做身份驗證，本質是創建一個ClaimsPrincipal，并根據當前請求創建一個證件（ClaimsIdentity），然后將此ClaimsIdentity加入到ClaimsPrincipal，最后將這個ClaimsPrincipal設定到HttpContext.User屬性上，身份驗證不是本篇重點，詳細描述參考：《asp.net core 3.x 身份驗證-1涉及到的概念》，我們目前只要記住一個字串代表一個身份驗證方案，它可以從當前請求或第三方去獲得一張證件（ClaimsIdentity）
當用戶登錄后，我們已經可以從HttpContext.User拿到當前用戶，里面就包含一張或多張證件，后續的權限判斷通常就依賴里面的資訊，比如所屬角色、所屬部門，除了證件的資訊我們也可以通過用戶id去資料庫中查詢得到更多用戶資訊作為權限判斷的依據，
資源
資源的概念很寬泛，上面說的銷售訂單、客戶檔案、屬于資源，我們可以控制某個用戶是否能查看、新增、審核訂單，或者說一個頁面也是一種資源，我們希望控制某用戶是否能訪問某個頁面，在asp.net core中直接以object型別來表示資源，因為asp.net core作為一個框架，它不知道將來使用此框架的開發者到底是對什么型別的資源做權限限制，
在我們日常開發中經常在Action上應用AuthorizeAttribute標簽來進行授權控制，其實這里就是將這個Action當做資源，由于目前asp.net core 3.x中默認使用終結點路由，所以現在在asp.net core 3.x中的默認授權流程中當前Endpoint就是資源
記住權限判斷中不一定需要資源的參與，比如只要用戶登錄，就允許使用系統中所有功能，此時整個系統就是資源，允許所有操作，
核心概念圖
授權依據IAuthorizationRequirement
試想這樣一種權限需求：要求屬于角色"經理"或"系統管理員"的用戶可以訪問系統任何功能，當我們做權限判斷時我們可以從HttpContext.User得到當前用戶，從其證件串列中總能找到當前用戶的所屬角色，那么這里需要進行比較的兩個角色"經理"、"系統管理員"從哪里獲得呢？
再比如：要求只要當前用戶的證件中包含一個"特別通行證"的Calim，就允許他訪問系統的任何功能，同上面的情況一樣，在判斷權限時我們可以知道當前登錄用戶的Calim串列，那需要進行比對的"特別通行證"這個字串從哪來呢？
asp.net core將這種權限判斷時需要用來比對的資料定義為IAuthorizationRequirement，我這里叫做"授權依據"，在一次權限判斷中可能會存在多個判斷，所以可能需要多個授權依據，檔案后面會講如何定制授權依據
其實某種意義上說“當前用戶（及其包含的Calim串列）”也可以看做是一種依據，因為它也是在授權判斷程序中需要訪問的資料，但是這個我們是直接通過HttpContext.User來獲取的，不需要我們來定義，
當我們針對某個頁面或Action進行授權時可以直接從當前路由資料中獲取Action名，在asp.net core 3.x中甚至更方便，可以在請求管道的早期就能獲得當前請求的終結點，所以針對Action的訪問也不需要定義成授權依據中
所以授權依據算是一種靜態資料，為了更好的理解，下面列出asp.net core中已提供的幾種授權依據
- ClaimsAuthorizationRequirement
public string ClaimType { get; } public IEnumerable<string> AllowedValues { get; }
將來在權限判斷是會判斷當前用戶的Claim串列中是否包含一個型別為ClaimType的Claim，若AllowedValues有資料，則進一步判斷是否完整包含AllowedValues中定義的值
- DenyAnonymousAuthorizationRequirement：權限判斷發現存在這個依據，則直接拒絕匿名用戶訪問
- RolesAuthorizationRequirement：這就是最常見的基于角色的授權時會使用的，它定義了 public IEnumerable<string> AllowedRoles { get; } ，將來做權限判斷時會看當前用戶是否屬于這里允許的角色中的一種
- OperationAuthorizationRequirement：這個也比較常用，在做功能授權時比較常用，它定義了 public string Name { get; set; } ，Name代表當前操作名，比如“Order.Add”就是新增訂單，將來權限判斷是可以根據當前用戶Id、所屬角色和"Order.Add"到資料庫去做對比
- AssertionRequirement：這個就更強大了，它定義了 public Func<AuthorizationHandlerContext, Task<bool>> Handler { get; } ，將來權限判斷時發現是這個型別，直接呼叫這個委托來進行權限判斷，所以靈活性非常大
授權策略AuthorizationPolicy
策略同時作為身份驗證方案和授權依據的容器，它包含本次授權需要的資料，
請求抵達時asp.net core會找到默認身份驗證方案進行身份驗證（根據請求獲取用戶ClaimsPrincipal），但有時候我們希望由自己來指定本次授權使用哪些身份驗證驗證方案，而不是使用默認的，這樣將來身份驗證程序中會呼叫設定的這幾個身份驗證方案去獲得多張證件，此時HttpContext.User中就包含多張證件，所以授權策略里包含多種身份驗證方案，
一次授權可能需要多種判斷，比如同時判斷所屬角色、并且是否包含哪種型別的Calim并且.....，某些判斷可能需要對比“授權依據”，所以一個授權策略包含多個授權依據，
另外我們可以將多個授權策略合并成一個對嗎？所有的身份驗證方案合并，所有的“授權依據”合并
將來授權檢查時將根據身份驗證方案獲取當前用戶的多個證件（里面包含很多Cliam可以用作權限判斷），然后逐個判斷授權依據，若都滿足則認為授權檢查成功，
若是針對某個資源的授權，授權方法大概是這樣定義的xxxx.Authorize(策略,訂單)，這里不一定直接傳入整個訂單，可能只傳入訂單金額，這個根據業務需要，若是簡單的情況只判斷頁面訪問權限，則xxx.Authorize(策略)，因為當前頁面可以直接通過當前請求獲取，
在asp.net core 3.x中啟動階段我們可以定義一個授權策略串列，這個看成是全域授權策略，一直存在于應用中，
在應用運行時，每次進行授權時會動態創建一個授權策略，這個策略是最終進行本次授權檢查用的，它可能會參考某一個或多個全域策略，所謂的參考就是合并其“身份驗證方案”串列和“授權依據串列”，當然其自身的“身份驗證方案”串列和“授權依據串列”也是可以定制的，待會在AuthorizeAttribute部分再詳細說
策略構造器AuthorizationPolicyBuilder
主要用來幫助創建一個授權策略（.net中典型的Builder模式），使用步驟是：
- new一個AuthorizationPolicyBuilder
- 呼叫各種方法對策略進行配置
- 最后呼叫Build方法生成最終的授權策略，
下面用偽代碼感受下
var builder = new AuthorizationPolicyBuilder(); builder.RequireRole("Manager","Admin"); //builder....繼續配置 var authorizationPolicy = builder.Build();
RequireRole將為最侄訓生成的策略中的“授權依據”串列加入一個RolesAuthorizationRequirement("Manager","Admin")，其它類似的api就不介紹了，
授權處理器AuthorizationHandler
上面說的當前用戶、授權依據、以及授權時傳遞進來的資源都是可以看成是靜態的資料，作為授權判斷的依據，真正授權的邏輯就是用IAuthorizationHandler來表示的,先看看它的定義
public interface IAuthorizationHandler { Task HandleAsync(AuthorizationHandlerContext context); }
AuthorizationHandlerContext
中包含當前用戶、授權依據串列和參與授權判斷的資源，前者是根據授權策略中的多個身份驗證方案經過身份驗證后得到的；后者就是授權策略中的授權依據串列，在方法內部處理成功或失敗的結果是直接存盤到context物件上的，
一個應用中可以存在多個AuthorizationHandler，在執行授權檢查時逐個呼叫它們進行檢查，若都成功則本次授權成功，
針對特定授權依據型別 的 授權處理器AuthorizationHandler<TRequirement>
上面聊過授權依據是有多種型別的，將來還可能自定義，通常授權依據不同，授權的判斷邏輯也不同，
- 比如RolesAuthorizationRequirement這個授權依據，它里面包含角色串列，授權判斷邏輯應該是判斷當前用戶是否屬于這里面的角色；
- 再比如OperationAuthorizationRequirement它里面定義了操作的名稱，所以授權判斷邏輯應該是拿當前用戶以及它所屬角色和這個操作（比如是“新增”）拿到資料庫去做對比
所以這樣看來一種“授權依據”型別應該對應一種“授權處理器”，所以微軟定義了public abstract class AuthorizationHandler<TRequirement> : IAuthorizationHandler ，這個TRequirement就代表這個授權處理器型別是針對哪種型別的“授權依據的”
一個授權策略AuthorizationPolicy是包含多個“授權依據”的，這其中可能有幾個“授權依據”的型別是一樣的，只是里面存盤的值不同，以OperationAuthorizationRequirement為例，一個授權策略里可能包含如下授權依據串列：
new OperationAuthorizationRequirement{ Name="新增" } new OperationAuthorizationRequirement{ Name="審核" } new RolesAuthorizationRequirement("Manager","Admin"); //其它，，，
所以一個授權處理器AuthorizationHandler雖然只關聯一種型別“授權依據”，但是一個授權處理器實體可以處理多個相同型別的“授權依據”
在授權程序中，每個AuthorizationHandler<TRequirement>會找到自己能處理的“授權依據”，逐個進行檢查
針對特定授權依據型別、特定型別的資源 的 授權處理器AuthorizationHandler<TRequirement, TResource>
定義是這樣的 public abstract class AuthorizationHandler<TRequirement, TResource> : IAuthorizationHandler
跟AuthorizationHandler<TRequirement>定義及處理邏輯唯一的區別是多了個TResource，在授權程序中是可以對給定資源進行判斷的，資源在AuthorizationHandlerContext.Resource，這個是object型別，為了方便子類降重重寫，所以由這里的父類將AuthorizationHandlerContext.Resource轉換為TResource
干脆貼下原始碼吧
1 public abstract class AuthorizationHandler<TRequirement> : IAuthorizationHandler 2 where TRequirement : IAuthorizationRequirement 3 { 4 public virtual async Task HandleAsync(AuthorizationHandlerContext context) 5 { 6 foreach (var req in context.Requirements.OfType<TRequirement>()) 7 { 8 await HandleRequirementAsync(context, req); 9 } 10 } 11 12 protected abstract Task HandleRequirementAsync(AuthorizationHandlerContext context, TRequirement requirement); 13 } 14 15 public abstract class AuthorizationHandler<TRequirement, TResource> : IAuthorizationHandler 16 where TRequirement : IAuthorizationRequirement 17 { 18 public virtual async Task HandleAsync(AuthorizationHandlerContext context) 19 { 20 if (context.Resource is TResource) 21 { 22 foreach (var req in context.Requirements.OfType<TRequirement>()) 23 { 24 await HandleRequirementAsync(context, req, (TResource)context.Resource); 25 } 26 } 27 } 28 29 protected abstract Task HandleRequirementAsync(AuthorizationHandlerContext context, TRequirement requirement, TResource resource); 30 }View Code
合并AuthorizationHandler & AuthorizationRequirement
我們發現通常一個授權依據的型別會有個對應的授權處理器，如果只定義一個類，實作這兩種介面事情不是更簡單嗎？舉個例子：
1 public class RolesAuthorizationRequirement : AuthorizationHandler<RolesAuthorizationRequirement>, IAuthorizationRequirement 2 { 3 public RolesAuthorizationRequirement(IEnumerable<string> allowedRoles) 4 { 5 AllowedRoles = allowedRoles; 6 } 7 public IEnumerable<string> AllowedRoles { get; } 8 protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, RolesAuthorizationRequirement requirement) 9 { 10 if (context.User != null) 11 { 12 bool found = false; 13 if (requirement.AllowedRoles == null || !requirement.AllowedRoles.Any()) 14 { 15 // Review: What do we want to do here? No roles requested is auto success? 16 } 17 else 18 { 19 found = requirement.AllowedRoles.Any(r => context.User.IsInRole(r)); 20 } 21 if (found) 22 { 23 context.Succeed(requirement); 24 } 25 } 26 return Task.CompletedTask; 27 } 28 }View Code
我們上面講的微軟定義的那幾個授權依據基本都是這樣定義的
何時實施授權檢查？
如果是用的asp.net core 3.x之前的版本，那么在Action執行前做授權判斷比較合適，常用的就是過濾器Filter咯，這個我不是特別確定，至少在.net framework時代是用的授權過濾器AuthorizeAttribute
請求 > 其它中間件 > 路由中間件 > 身份驗證中間件 > MVC中間件 > Controller > [授權過濾器]Action
若是asp.net core 3.x之后，由于目前用的終結點路由，所以在 路由中間件 和 身份驗證中間件 后做權限判斷（使用授權中間件）比較合適，因為 路由中間件執行后我們可以從當前請求背景關系中獲取當前終結點（它代表一個Action或一個頁面），身份驗證中間件執行后可以通過HttpContext.User獲取當前用戶，此時有了訪問的頁面和當前用戶 就可以做權限判斷了
請求 > 其它中間件 > 路由中間件（這里就拿到終結點了） > 身份驗證中間件 > 授權中間件 > MVC中間件 > Controller > Action
還有一種情況是在業務代碼內部去執行權限判斷，比如：希望銷售訂單金額大于10000的，必須要經理角色才可以審核，此時因為我們要先獲取訂單才知道它的金額，所以我們最好在Action執行內部根據路由拿到訂單號，去資料庫查詢訂單金額后，呼叫某個方法執行權限判斷，
授權服務AuthorizationService
所以執行權限判斷的點不同，AuthorizationService就是用來封裝授權檢查的，我們在不同的點都可以來呼叫它執行權限判斷，看看介面定義
public interface IAuthorizationService { Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object resource, IEnumerable<IAuthorizationRequirement> requirements); Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object resource, string policyName); }
user：要進行判斷的用戶，它里面可能存在一張或多張證件
resource：可能是一個終結點，也可能是一個頁面RazorPage，也可能是一個訂單（或者是單獨的訂單金額）
requirements：授權依據串列
policyName：一個授權策略名
在授權中間件和在業務邏輯代碼中手動進行授權檢查時都是呼叫此介面
它內部會去呼叫AuthorizationHandler來進行權限判斷，
定制授權依據AuthorizeAttribute : IAuthorizeData
在asp.net core 3.x中 啟動階段可以配置一個全域策略串列，它一直存在于系統中，暫時稱為“靜態策略串列”
在每次執行授權檢查時也需要一個策略，暫時稱為“運行時授權策略”，授權中間件執行時就會創建此策略，然后呼叫AuthorizationService根據此策略進行權限判斷，那此策略中的“授權依據”和“身份驗證方案”這倆串列從哪來的呢？就是在Action通過AuthorizeAttribute來定制的，它實作 IAuthorizeData介面
如果你對早期版本mvc有一丟丟了解的話，你可能記得有個授權過濾器的概念AuthorizeAttribute，在Action執行前會先去做授權判斷，若成功才會繼續執行Action，否則就回傳403.
在asp.net core 3.x中不是這樣了，AuthorizeAttribute只是用來定制當前授權策略（AuthorizationPolicy）的，并不是過濾器，它實作IAuthorizeData介面，此介面定義如下：
public interface IAuthorizeData { string Policy { get; set; }//直接指定此Action將來授權驗證時要使用的授權策略AuthorizationPolicy，此策略會被合并到當前授權策略 string Roles { get; set; } //它會創建一個基于角色的授權依據RolesAuthorizationRequirement，此依據會被放入當前授權策略 string AuthenticationSchemes { get; set; }//它用來定義當前授權策略里要使用哪些身份驗證方案 }
Policy屬性指明從“靜態策略串列”拿到指定策略，然后將其“授權依據”和“身份驗證方案”這倆串列合并到“運行時授權策略”
看個例子：
1 [Authorize(AuthenticationSchemes = "cookie,jwtBearer")] 2 [Authorize(Roles = "manager,admin")] 3 [Authorize(policy:"test")] 4 [Authorize] 5 public IActionResult Privacy() 6 { 7 return View(); 8 }
以上定制只是針對使用授權中間件來做權限判斷時，對當前授權策略進行定制，若我們直接在業務代碼中呼叫AuthorizationService手動進行權限判斷呢，就截止呼叫咯，參考上面的描述
授權中間件AuthorizationMiddleware
上面我們介紹了何時實施授權檢查，授權中間件（AuthorizationMiddleware）就是其中最為常用的一個授權檢查點，相當于是一個授權檢查的入口方法，它在進入MVC中間件之前就可以做授權判斷，所以比之前的在Action上做判斷更早，并且由于授權檢查是根據終結點的，因此同一套授權代碼可以應用在mvc/webapi/razorPages...等多種web框架，由于授權檢查依賴當前訪問的終結點（若不理解終結點，可以暫時認為它=Action及其之上應用的各種Attribute） 和 當前登錄用戶，因此 授權中間件 應該在 路由中間件 和 身份驗證中間件 之后注冊
1 public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
2 {
3 //略....
4 app.UseHttpsRedirection();
5 app.UseStaticFiles();
6 app.UseRouting();
7 app.UseAuthentication();
8 app.UseAuthorization();
9 app.UseEndpoints(endpoints =>
10 {
11 endpoints.MapRazorPages();
12 });
13 }
它的核心步驟大致如下：
- 從當前請求拿到終結點
- 通過終結點拿到其關聯的IAuthorizeData集合
- 通過IAuthorizeData集合創建一個復合型授權策略
- 遍歷策略中的身份驗證方案獲取多張證件，最后合并放入HttpContext.User中
- 若Action上應用了IAllowAnonymous，則放棄授權檢查（為毛不早點做這步？）
- 呼叫IAuthorizationService執行授權檢查
- 若授檢查結果為質詢，則遍歷策略所有的身份驗證方案，進行質詢，若策略里木有身份驗證方案則使用默認身份驗證方案進行質詢
- 若授權評估拒絕就直接呼叫身份驗證方案進行拒絕
所以重點是可以在執行mvc中間件之前拿到終結點及其之上定義的AuthorizeAttribute，從其中的資料就可以構建出本次權限判斷的“授權策略”，有了授權策略就可以通過AuthorizationService執行授權判斷，內部會使用到授權處理器AuthorizationHandler
結束
暫時就BB到這里，先有個大概印象，下一篇按asp.net core的默認授權流程走走原始碼，再結合此篇應該就差不多了...
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/67581.html
標籤：其他