.Net Core 認證系統源碼解析

       不知不覺.Net Core已經推出到3.1了,大多數以.Net爲技術棧的公司也開始逐步的切換到了Core,從業也快3年多了,一直堅持着.無論環境怎麼變,堅持本身的當初的選擇,堅持信仰 .Net Core是個很是優秀的框架,若是各位是從WebForm開始,一步步走到今天,天然而然就會發現.微軟慢慢的開始將整個框架組件化,不在像之前那樣,因此的東西都傻瓜化,好比WebForm,拖拖控件每每能搞定大部分的事情.Core的擴展性很好,將不少選擇權交給咱們本身,而不是強行的讓咱們去接受他那一套,對第三方組件的兼容性很好.換句話說,不少核心組件微軟提供了高層抽象,若是你想換,能夠,不想換,也能夠,用他默認的實現.其餘的優缺點也不一一細說了,也不是本文的重點。若是時間容許,建議你們能夠深刻的研究.Net Core的底層.

一、簡介

省去前面的建立Core Web項目的一系列操做.VS幫你自動化初始化好全部的基礎組件、環境.第一步就是認證.就是登錄.固然微軟提供了一套登錄組件.很全,很完善。項目在Core源碼 

 Security文件夾下,源碼自行去github下載.裏面提供了若干個認證方法,常見的Cookie認證、JwtBear認證等等.還包括FaceBook、Google等遠程認證方式.

本文暫時不講解具體的認證方式,主要闡述核心認證流程.

 

(1)、認證系統的執行過程

Core啓動認證系統的方式很簡單

 

 很簡單的一段代碼,看看它幹了什麼

 

 很簡單,注入認證中間件,關於中間件這裏就不說多,不是文本的重點,自行百度.看看中間價幹了什麼.

 

 核心代碼,首先拿到DI中注入的處理認證請求處理器集合,接着去DI中獲取認證處理方案集合中的處理認證請求上下文的方案類.接着去處理器集合中拿處處理認證請求上下文的方案類對應的認證請求處理器,接着執行處理器的HandleRequestAsync方法,完成認證請求上下文的處理.這意味着咱們的認證請求參數是能夠被咱們作特殊處理的.

 

接着

 

 處理完認證請求參數以後,接着去認證方案中拿到默認的認證方案,不爲空,執行上下文的擴展方法context.AuthenticateAsync,這個方法幹了什麼以下:

 

 執行DI中注入的認證服務方法,並傳入上下文和默認的認證方案名稱.

 

 先判斷存不存在默認認證方案,不存在拋異常,接着去全部的認證處理器集合中拿到默認認證方案的處理器.接着調用處理的認證方法,認證成功,判斷當前用戶身份集合中在臨時緩存中存不存在,不存在,能夠執行Claim的轉換.這很好,說明用戶認證成功以後的Cliam也是能夠被轉換的.

 

 只要注入IClaimsTransformation服務便可,你就能夠執行你須要的業務的Claim轉換，最後返回結果

 到這裏整個認證流程結束.很是的簡單.且關鍵點的擴展微軟都預留了.能夠自定義實現

 

(2)、流轉服務的介紹.

上面介紹了整個認證組件的流轉過程,由於我對流程很清楚,因此你們可能仍是不理解.因此接下去開始介紹流轉必須服務的注入.

 認證處理器的Provider類,那麼Core實在哪裏注入認證處理器的呢?

 

 這裏,核心也是紅框裏的,下面的只是一些依賴組件。

 

 微軟注入默認的認證處理器.看下獲取處理器的實現,對應中間件.

 

 閱讀源碼發現,Provider類並不具體實現提供認證處理器的方法.而是經過SchemeProvider來提供.

 

原來是IAuthenticationSchemeProvider類提供認證處理器.並且是經過反射實現(這點開銷,就不必考慮性能問題,固然你能夠考慮重構),那麼問題來了,在哪裏出入IAuthenticationSchemeProvider服務內,回到上面那張圖

 

 微軟也提供了默認實現,去看看GetSchemeAsync方法的實現

 

 

 ok,到這裏就說明認證處理器經過向這個字典寫入值,來實現的.也就是微軟認證方案提供了認證處理器.

 

 上面是認證方案的核心字段,HandlerType就是認證處理器.

AuthenticationSchemeProvider類維護了一個_schemes的字典,經過它向外輸出.認證方案集合提供類.

 接着認證處理器集合提供類AuthenticationHandlerProvider經過解析

認證方案集合提供類,拿到全部的認證處理器.

到這裏,很明顯,全部的認證處理器都是經過向AuthenticationSchemeProvider的_schemes字典注入認證處理器.既然如此,入口在哪？在AuthenticationBuilder類下面.

 下面是Cookie認證方式注入認證處理器的方式

 AddScmeme方法.在配置參數的同時,指定了處理器.

 

 接着,回到中間件的圖

 咱們經過AuthenticationBuilder的AddScheme方法向_schemes集合寫入了認證處理器且配置了處理器的參數,接着經過AuthenticationHandlerProvider拿到了全部的認證處理器.

接着咱們經過Schemes方案集合拿到全部處理認證請求上下文的處理器,執行處理認證請求上下文參數.處理完畢.

 

接着咱們解析Schemes中提供的默認認證方案,代碼以下:

 根據

 這個配置參數,通常在入口注入:

 中配置默認方案名稱,拿到默認認證方案.再將處理過的認證請求上下文和默認方案傳給IAuthenticationService,這個Service也有默認實現,以下:

 

 AuthenticationService將處理過的認證請求上下文交給具體的認證請求處理器來處理.並返回處理結果.認證請求處理器前面說過了,經過AuthenticationBuilder的AddScheme方法來注入.

到這裏,整個組件的流程介紹結束.純屬我的理解,能力有限,有問題,請指正,謝謝.

下面開始介紹基於Cookie的認證組件.