.Net Core 受權系統組件解析

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

一、認證組件的執行流程前端

Core啓動認證組件的方式很簡單.git

 

 和認證系統同樣,都是以中間件的形式提供服務.github

 驗證有沒有注入受權組件的核心服務. 後端

接下去查看中間件的代碼,以下:設計模式

 

 

 

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

 從終結點元數據中讀取打了Authorize的特性的控制器和方法.那麼意味這此時控制器已經被注入了,因此通常services.AddMvc()和add.UseMvc()是先於認證組件注入的.架構

且微軟提示,若是你自定義了一個受權Filter,改變了認證邏輯,可能會形成錯誤,不建議這種方式.由於核心認證組件支持全部的業務擴展,不必再去定義額外的Filter.ide

接着看以下代碼:post

 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的受權認證中心作準備.最後造成一個完整的受權認證中心.

g

相關文章
相關標籤/搜索