.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等等），看得我很暈，最后總算搞明白了一些，很多細節也沒去深究，文中內容有的基於代碼，有的基於個人理解，有錯誤希望大家嘴下留情。