1. 程式人生 > >.Net Core 授權系統元件解析

.Net Core 授權系統元件解析

前面關於.Net Core如何進行使用者認證的核心流程介紹完畢之後,.Net Core 認證系統之Cookie認證原始碼解析遠端認證暫時不介紹,後期有時間,我會加上.接下去介紹認證元件是如何和認證元件一起協同工作.原始碼的路徑如下,自行去github下載.ok,開始!

1、認證元件的執行流程

Core啟動認證元件的方式很簡單.

 

 和認證系統一樣,都是以中介軟體的形式提供服務.

 驗證有沒有注入授權元件的核心服務. 

接下去檢視中介軟體的程式碼,如下:

 

 

 

 校驗過程就不說了,第一步:

 從終結點元資料中讀取打了Authorize的特性的控制器和方法.那麼意味這此時控制器已經被注入了,所以一般services.AddMvc()和add.UseMvc()是先於認證元件注入的.

且微軟提示,如果你自定義了一個授權Filter,改變了認證邏輯,可能會造成錯誤,不建議這種方式.因為核心認證元件支援所有的業務擴充套件,沒必要再去定義額外的Filter.

接著看如下程式碼:

 AuthorizationPolicy類合併了需要認證的元資料和認證策略提供類.那去找找IAuthorizationPolicyProvider介面的實現,如下

 在注入服務的時候,微軟注入了預設的實現,又是Provider模式,Core底層大量採用了這個模式,所以如果你不知道,先去補補設計模式的知識點,可以參考本人的設計模式分類.這個設計模式很簡單.不看程式碼就能猜出大致的實現,內部肯定維護了一個鍵值對,Dic或者HashMap.那就去看看.

 

 呼叫了AuthorizationOptions引數中的GetPolicy方法,對應

 果然是個字典.這意味這我們可以通過認證引數來配置認證策略,新增策略的方法如下:

 ok,再去看看AuthorizationPolicy的構造,其維護了兩個主要的屬性,後面會介紹.

 一個認證方案的名稱和一個授權條件集合,到這裡可以知道認證元件可以和授權元件整合到一起使用的結論.

講到這,回到中介軟體

 _prolicyProvider提供的是認證方案的名稱和授權條件集合,以及需要被認證的元資料集合.

接著,看看AuthorizationPolicy.CombineAsync的實現

 

 

 

 跳過引數校驗,分析核心程式碼,第一步:

 遍歷需要授權的元資料集合

 AuthorizationPolicyBuilder,授權策略Buidler生成器,負責生成授權策略。Buidler生成器模式,不懂其移步本人設計模式分類,很簡單.

 判斷需要授權元資料的Policy屬性,ok,到這裡.很明顯.我們得看看Authorize特性

 

 

 這個時候

 紅框裡得值就為"自定義授權策略",接著通過policyProvider拿到對應得AuthorizationPolicy例項,本質就是認證策略名稱為"自定義授權策略"的認證方案和授權條件集合.

接著通過policyBuilder將認證策略名稱為"自定義授權策略"的認證方案和授權條件集合.

 新增到AuthorizationPolicyBuilder例項的下面兩個屬性中去

 此時,當你這樣設定控制器或者其下的方法

 說明你不在採用授權元件的預設策略,所以

 接著

 又去判斷當前需要授權元資料的Authorize特性中是否設定了Roles特性,且可以設定多個,以","分隔

 

 到這裡說明自定義策略授權和Role授權是可以共存的,可以向下面這樣

接著

 

 這個方法本質,就是向AuthorizationPolicyBuilder例項的

 追加授權條件.

簡單說下為什麼微軟要給授權元件預留Roles角色集合,因為當前市面上主流的許可權設計系統都是RBAC模式,中文就是基於角色(Role)的許可權管理系統.

接著

 這裡和角色一樣不介紹了

到這裡你會發現 基於認證方案授權策略+基於角色的授權策略=自定義策略的授權策略.

接著,如果沒有任何控制器或者方法使用授權策略,那麼使用最基本的拒絕匿名訪問api策略

 核心程式碼如下:

 如果當前使用者未認證,則不能訪問.

當然這個策略也可以通過AuthorizationOptions引數進行重寫.

 最後

 去重構建一個新的PolicyBuilder物件例項.

 接著

 

 執行PolicyBuilder中的使用者認證,其中做了一些重複登陸的處理.本質就是如此.

 這段程式碼就可以看出.如果當前使用者未登陸,則返回

 接著回到中介軟體

 認證完畢之後,如果當前元資料打了AllowAnonymous特性像下面這樣

 這樣意味這之前的工作都白做了.直接跳過授權.

最後

 

 呼叫授權服務,進行授權校驗.預設的授權服務注入點如下:

 構建授權上下文,接著拿到所有的授權處理器.遍歷執行

 這個引數,可配置,當一個授權策略校驗失敗,便不再執行接下去的授權策略.

最後返回授權結果

總結:本質就是將

 特性中的這兩個引數,交給IAuthorizationHandler授權處理器處理.當然如果你制定了認證方案,那麼則會去判斷當前使用者是否登陸.

  整個流程結束.純屬個人理解,能力有限,有問題,請指正,謝謝.

 

接下去會寫一篇動態授權的文章,這樣就能將授權元件+認證元件+許可權系統集合起來實現完成使用者認證和api動態授權.為後期的前端後端分離架構-基於id4的password模式+JwtBear認證+identity的授權認證中心做準備.最後形成一個完整的授權認證中心.