不知不覺.Net Core已經推出到3.1了,大多數以.Net為技術棧的公司也開始逐步的切換到了Core,從業也快3年多了,一直堅持着.不管環境怎么變,堅持自己的當初的選擇,堅持信仰 .Net Core是個非常優秀的框架,如果各位是從WebForm開始,一步步走到今天,自然而然就會發現.微軟慢慢的開始將整個框架組件化,不在像以前那樣,所以的東西都傻瓜化,比如WebForm,拖拖控件往往能搞定大部分的事情.Core的擴展性很好,將很多選擇權交給我們自己,而不是強行的讓我們去接受他那一套,對第三方組件的兼容性很好.換句話說,很多核心組件微軟提供了高層抽象,如果你想換,可以,不想換,也可以,用他默認的實現.其他的優缺點也不一一細說了,也不是本文的重點。如果時間允許,建議大家可以深入的研究.Net Core的底層.
1、簡介
省去前面的創建Core Web項目的一系列操作.VS幫你自動化初始化好所有的基礎組件、環境.第一步就是認證.就是登陸.當然微軟提供了一套登陸組件.很全,很完善。項目在Core源碼
Security文件夾下,源碼自行去github下載.里面提供了若干個認證方法,常見的Cookie認證、JwtBear認證等等.還包括FaceBook、Google等遠程認證方式.
本文暫時不講解具體的認證方式,主要闡述核心認證流程.
(1)、認證系統的執行過程
Core啟動認證系統的方式很簡單
很簡單的一段代碼,看看它干了什么
很簡單,注入認證中間件,關於中間件這里就不說多,不是文本的重點,自行百度.看看中間價干了什么.
核心代碼,首先拿到DI中注入的認證請求處理器集合,接着去DI中獲取認證處理方案集合中的處理認證請求上下文的方案類.接着去處理器集合中拿到處理遠程認證請求上下文的方案類對應的認證請求處理器,接着執行處理器的HandleRequestAsync方法,完成遠程認證的處理.
接着
遠程認證流程執行完畢之后,直接return.反之,如果當前不是使用遠程認證,接着去認證方案中拿到默認的認證方案,不為空,執行上下文的擴展方法context.AuthenticateAsync,這個方法干了什么如下:
執行DI中注入的認證服務方法,並傳入上下文和默認的認證方案名稱.
先判斷存不存在默認認證方案,不存在拋異常,接着去所有的認證處理器集合中拿到默認認證方案的處理器.接着調用處理的認證方法,認證成功,判斷當前用戶身份集合中在臨時緩存中存不存在,不存在,可以執行Claim的轉換.這很好,說明用戶認證成功之后的Cliam也是可以被轉換的.
只要注入IClaimsTransformation服務即可,你就可以執行你需要的業務的Claim轉換，最后返回結果
到這里整個認證流程結束.非常的簡單.且關鍵點的擴展微軟都預留了.可以自定義實現
(2)、流轉服務的介紹.
上面介紹了整個認證組件的流轉過程,因為我對流程很清楚,所以大家可能還是不理解.所以接下去開始介紹流轉必須服務的注入.
認證處理器的Provider類,那么Core是在哪里注入認證處理器的呢?
這里,核心也是紅框里的,下面的只是一些依賴組件。
微軟注入默認的認證處理器.看下獲取處理器的實現,對應中間件.
閱讀源碼發現,Provider類並不具體實現提供認證處理器的方法.而是通過SchemeProvider來提供.
原來是IAuthenticationSchemeProvider類提供認證處理器.而且是通過反射實現(這點開銷,就沒必要考慮性能問題,當然你可以考慮重構),那么問題來了,在哪里出入IAuthenticationSchemeProvider服務內,回到上面那張圖
微軟也提供了默認實現,去看看GetSchemeAsync方法的實現
ok,到這里就說明認證處理器是通過向這個字典寫入值,來實現的.
上面是認證方案AuthenticationScheme類的核心字段,HandlerType就是認證處理器.
AuthenticationSchemeProvider類維護了一個_schemes的字典,通過它向外輸出.認證方案集合提供類.
接着認證處理器集合提供類AuthenticationHandlerProvider通過解析
認證方案集合提供類,拿到所有的認證處理器.
到這里,很明顯,所有的認證處理器都是通過向AuthenticationSchemeProvider的_schemes字典注入認證處理器.既然如此,入口在哪？在AuthenticationBuilder類下面.
下面是Cookie認證方式注入認證處理器的方式
AddScmeme方法.在配置參數的同時,指定了處理器.
接着,回到中間件的圖
我們通過AuthenticationBuilder的AddScheme方法向_schemes集合寫入了認證處理器且配置了處理器的參數,接着通過AuthenticationHandlerProvider拿到了所有的認證處理器.
接着我們通過Schemes方案集合拿到所有處理認證請求上下文的處理器,執行處理認證請求上下文參數.處理完畢.
接着我們解析Schemes中提供的默認認證方案,代碼如下:
根據
這個配置參數,一般在入口注入:
中配置默認方案名稱,拿到默認認證方案.再將處理過的認證請求上下文和默認方案傳給IAuthenticationService,這個Service也有默認實現,如下:
AuthenticationService將處理過的認證請求上下文交給具體的認證請求處理器來處理.並返回處理結果.認證請求處理器前面說過了,通過AuthenticationBuilder的AddScheme方法來注入.
到這里,整個組件的流程介紹結束.純屬個人理解,能力有限,有問題,請指正,謝謝.
下面開始介紹基於Cookie的認證組件.