.NET Core認證管理解析

.NET Core中的認證管理解析

0x00 問題來源

在建立.NET Core的Web項目時選擇“使用個人使用者賬戶”就可以建立一個帶有使用者和許可權管理的項目，已經準備好了使用者註冊、登入等很多頁面，也可以使用AuthorizeAttribute進行各種許可權管理，看起來似乎十分方便。不過產生的程式碼都替我幹了些什麼我一團霧水。看了下產生的資料表，功能也挺複雜的。實際上我需要的只是基於使用者和角色的認證管理，而且使用者資料是使用現有的庫，但使用.NET Core內建的認證組件必須要依賴EF，表的結構也很多對不上，所以學習了下內建的認證組件的實現，然後自己寫了個認證服務替換了Identity組件，同時Cookie管理使用內建的Cookie中介軟體、可以使用AuthorizeAttribute進行認證。複雜的需求還沒遇到，所以就學習到了這裡。這篇部落客要討論最簡單情況下的的基於使用者和角色的認證。關於.NET Core內建認證組件的一些基本用法，可以參考http://www.php.cn/。

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。

登入：

註冊：

登出：

只是為了測試，邏輯上很多問題，比如使用者密碼明文儲存。重點看過程:)

0x05 寫在最後

第一次接觸Web應用，很多概念都不是很瞭解。就拿Cookie認證使用者來說，我之前的只知道通過Cookie識別使用者，一直以為是收到Cookie後再從資料庫或緩衝中查出相應的許可權資訊。不過看了內建的Cookie中介軟體代碼後才知道認證資訊是直接存在Cookie中的，這樣只要解密後還原序列化就可以了。Identity這個程式集涉及了很多其它程式集（Security、HttpAbstraction等等），看得我很暈，最後總算搞明白了一些，很多細節也沒去深究，文中內容有的基於代碼，有的基於個人理解，有錯誤希望大家嘴下留情。