.NET Core中的認證管理解析
0x00 問題來源
在新建.NET Core的Web專案時選擇“使用個人使用者賬戶”就可以建立一個帶有使用者和許可權管理的專案，已經準備好了使用者註冊、登入等很多頁面，也可以使用AuthorizeAttribute進行各種許可權管理，看起來似乎十分方便。不過生成的程式碼都替我幹了些什麼我一團霧水。看了下生成的資料表，功能也挺複雜的。實際上我需要的只是基於使用者和角色的認證管理，而且使用者資料是使用現有的庫，但使用.NET Core自帶的認證元件必須要依賴EF，表的結構也很多對不上，所以學習了下自帶的認證元件的實現，然後自己寫了個認證服務替換了Identity元件，同時Cookie管理使用自帶的Cookie中介軟體、可以使用AuthorizeAttribute進行認證。複雜的需求還沒遇到，所以就學習到了這裡。這篇部落格主要討論最簡單情況下的的基於使用者和角色的認證。關於.NET Core自帶認證元件的一些基本用法，可以參考https://docs.asp.net/en/latest/security/authentication/accconfirm.html。
0x01 .NET Core中的認證管理
提到認證管理，首相想到的就是使用者的註冊、登入、登出以及給使用者新增/刪除角色等功能。其中使用者資訊，角色資訊等都是儲存在資料庫中的。所以主要包含資料庫操作和登入業務邏輯兩部分。在登入業務邏輯層面，.NET Core主要通過三個比較核心的類UserManager、RoleManager、SigninManager進行管理（在Microsoft.AspNetCore.Identity程式集）。其中：
- UserManager主要負責使用者的認證、註冊、修改、刪除以及與使用者相關的角色、令牌、宣告等的管理。
- RoleManager負責角色、角色相關宣告的管理。
- SigninManager負責登入、登出等相關操作。在涉及到使用者操作（如登陸時使用者驗證）會呼叫UserManager進行操作。
這三個核心類在運算元據庫時，使用資料庫層面的UserStore、RoleStore進行操作（在Microsoft.AspNetCore.Identity.EntityFrameworkCore程式集）。業務關係如下圖所示：
我們在開發認證相關功能時使用這三個核心類即可滿足大多數需求。我們在使用這幾個核心類的物件時都是通過依賴注入獲取的，那麼這些相關的依賴是什麼時候注入的呢？在Startup的ConfigureServices方法中有AddIdentity擴充套件方法，就是在這個方法中新增了需要的所有依賴。
0x02 登入和登出
瞭解了Identity元件的整體分工後，再來看一下登入和登出的操作的部分細節。登入和登出過程主要由SigninManager負責，的先來看一下登入的過程：
登入成功後Response的Header中包含了Set-Cookie，Cookie的Key需要和Cookie中介軟體中設定的要解密的Cookie的Key一致，在截圖中這個Cookie的Key是IdentityCookie。設定Cookie的同時返回302重定向到登入頁面。
重定向到登陸頁面時，請求中已經帶有設定的Key為IdentityCookie的Cookie了。
登出過程比較簡單，呼叫HttpContext.Authentication.SignOutAsync方法即可登出，此時會給HttpContext.Response新增Set-Cookie，但內容為空。
0x03 通過Cookie識別使用者
.NET Core中通過CookieAuthenticationMiddleware這個中介軟體識別HttpContext中認證相關的Cookie，從而新增使用者的驗證和授權資訊。最關鍵的是ClaimsPrincipal物件，它記錄使用者的認證和授權資訊（除此之外當然也可以包含其它你需求的任意資訊），從上面登入過程可以看到，登入成功後使用者認證和授權資訊儲存至ClaimsPrincipal物件（實際上對於這條Cookie鍵值對中的認證資訊儲存為ClaimsIdentity，一個ClaimsPrincipal可以包含多個ClaimsIdentity），然後在HttpContext.Response的Headers中新增Set-Cookie，Key為Cookie中介軟體中指定的CookieName，Value就是這個物件加密後的字串。以後的HttpContext都會帶有這個Cookie，Cookie中介軟體會把符合這個CookieName的Cookie取出來，解密並還原為ClaimsPrincipal物件，並把HttpContext.User設定為這個物件。後面MVC中介軟體在路由到相應Controller和Action的時候就可以根據Authorize特性中指定的認證和角色在HttpContext.User中進行檢查，不滿足檢查則跳轉至相應頁面。因此需要注意的就是一定要把Cookie中介軟體放在MVC中介軟體之前。
這裡需要特別說一下ClaimsPrincipal。一個ClaimsPrincipal物件中包含了一個或多個ClaimsIdentity物件，一個ClaimsIdentity物件一般來說對應著一個Cookie中某條鍵值對（個人理解）。Cookie中介軟體和ClaimsIdentity是通過AuthenticationScheme聯絡起來的。後面我們在寫自己的認證服務時，也是把Cookie中介軟體的AuthenticationScheme和建立的ClaimsIdentity一致。所以更準確地說是ClaimsIdentity包含了使用者認證和許可權的宣告，而ClaimsPrincipal可以包含多個ClaimsIdentity。當管道中存在多個Cookie中介軟體時，通過AuthenticationScheme進行區分。
在ClaimsIdentity中除了AuthenticationScheme外還有兩個比較重要的屬性，UserType和RoleType，其中UserType指定了使用者驗證型別，RoleType指定可角色驗證型別。意思就是如果我指定了RoleType為”RoleName”，那麼在進行角色認證時就會尋找Claims中所有的Type為”RoleName”的值，並檢查其中是否包含了Authorize中指定的RoleName。不過.NET Core中自帶了ClaimTypes，可以直接使用。例如角色型別就是ClaimTypes.Role。如果新增角色時用的自帶的ClaimTypes.Role，那麼在建立ClaimsIdentity時就不需要顯示指定RoleType了，預設角色認證就是使用ClaimTypes.Role。
關於Cookie中介軟體的新增，是通過Startup中Configure方法中的app.UseIdentity擴充套件方法實現的。這個擴充套件方法實際上新增了多種Cookie識別方式。在後面我在寫自己的使用者認證管理時只用一種。
0x04 自己寫使用者認證管理
瞭解了使用者認證的過程，我們可以自己寫認證管理來代替Identity元件了，同樣分為資料庫操作和認證業務邏輯。資料庫相關就不多說了，都寫到了IdentityRepository類，只有很簡單的資料操作。為了方便使用了Dapper，資料庫用的Sqlite。程式在啟動時會檢查資料庫表，沒有會自動建立空表。
認證服務也比較簡單就都寫到了IdentityService類，提供了註冊和登入操作，登出太簡了直接寫在了Action裡。為了方便沒有提供角色管理頁面，如果要測試角色認證功能，需要手動去資料庫新增Role，然後在UserRoles中給使用者新增Role。
登入：
註冊：
登出：
具體示例可以到：
https://github.com/durow/NetCoreStudy
只是為了測試，邏輯上很多問題，比如使用者密碼明文儲存。重點看過程:)
0x05 寫在最後
第一次接觸Web應用，很多概念都不是很瞭解。就拿Cookie認證使用者來說，我之前的只知道通過Cookie識別使用者，一直以為是收到Cookie後再從資料庫或快取中查出相應的許可權資訊。不過看了自帶的Cookie中介軟體程式碼後才知道認證資訊是直接存在Cookie中的，這樣只要解密後反序列化就可以了。Identity這個程式集涉及了很多其它程式集（Security、HttpAbstraction等等），看得我很暈，最後總算搞明白了一些，很多細節也沒去深究，文中內容有的基於程式碼，有的基於個人理解，有錯誤希望大家嘴下留情。
更多內容歡迎訪問我的部落格：http://www.durow.vip