本期配套視頻：

https://www.bilibili.com/video/BV1sJ41197af?p=9

（昔我往矣，楊柳依依，今我來思，雨雪霏霏）

1、為什么需要在認證內部加權

我們知道，認證中心的作用就是用來保護我們的資源服務器，所以說認證中心是一個保護者，當然，他在保護其他客戶端的時候，也需要對自己進行保護，舉例來說：

我的Ids4項目中，有用戶角色信息管理，客戶端數據管理等等，這些不可能讓普通的登錄用來來訪問的

因此我們同樣需要在認證中心內部實現加權處理，用來保護某些頁面或者說某些數據的安全性不被惡意攻擊或訪問。

當然除了不讓普通用戶訪問，我們也同樣為了區分公司內部管理員的身份和權限，也同樣需要如此，超級管理員有很高的權限，可以處理任意數據。

這就是為什么我們需要在認證中心內部進行權限管理的原因。

2、常見的加權方式有哪幾種

這個問題不僅僅是在認證中心，其實在任何的項目中，包括資源服務器中，我們也是常用這幾種權限處理方式，多數是基于角色控制的RBAC模式：

這幾種我都使用過，也都是各有利弊的，我在資源服務器Blog.Core中，用的是第④種，而這次在認證中心Blog.IdentityServer中，使用的是第③種。

第四種是最復雜的，保存到數據庫，可以實現動態的策略授權，我們通過配置數據庫，就可以針對任意一個頁面或者API進行控制，但是在認證中心中，有些過于復雜了，故暫時不用。

第一種是無狀態的，任意登錄的用戶都能訪問，起不到控制的作用，僅僅是起到防止那些訪客任意訪問的作用，故舍棄。

第二種其實和第三種是一樣的代碼，我舉例來說明：

services.AddAuthorization(options =>{options.AddPolicy("Admin", policy => policy.Requirements.Add(new ClaimRequirement("rolename", "Admin")));options.AddPolicy("SuperAdmin", policy => policy.Requirements.Add(new ClaimRequirement("rolename", "SuperAdmin")));});services.AddSingleton<IAuthorizationHandler, ClaimsRequirementHandler>();

從代碼中，我們可以看到，我雖然創建了一個簡單的策略，但是邏輯卻是獲取rolename角色名，判斷各自的角色，那我為啥不直接用第二種呢：

這樣豈不是更簡單，也不用寫處理器等邏輯了，直接這么寫一下即可。

下邊我會講為什么沒有用這個。

3、你的資源服務器是如何加權的

你可能會好奇，今天說的是認證中心的加權，為啥又說到了資源服務器？是不是多此一舉了，并不是，其實我們寫的每一行代碼都應該考慮下，是否對其他的有影響，是否對其他的項目有關聯，今天說的認證中心也是，我先給大家回憶一下Blog.Core的資源服務器是如何權限控制的。

Blog.Core中，用到的是上面說的第四種，復雜數據庫的策略授權，我們把數據都配置到了數據庫中，通過角色+菜單+接口的三方約束，來實現當前用戶是否有權利訪問當前接口。

細心的你可能發現了，這個多對多的關系表中，我們用到的是RoleId，那這個Id是從哪里來的，肯定是從Ids4認證中心來的，畢竟用戶是在那里統一登錄注冊。

那是如何傳遞過來的，肯定是Token，進一步說明，是Token中的Cliams聲明，那我們繼續往前推，這個聲明是從哪里配置的？是這里：

這里用SeedData來舉例，生成種子數據的時候，我們把角色Id賦給了JwtClaimTypes.Role的Cliams節點，這個是一個常量，也就等于是role這個節點。

這樣的話，我們Token中的聲明中的role節點，其實就是我們的角色Id，那上邊反推的邏輯就成功了，我們再來總結下：

用戶登錄——>獲取token——>攜帶roleid——>資源服務器HttpContext解析token

——>得到roleid——>根據roleid獲取到指定的菜單mid和接口pid集合——>在策略授權中做邏輯判斷。

看似一切很合理，但是卻有一個問題，因為我Blog.Core是先開發的，所以假設我們的這個資源服務器代碼不改的話，認證中心就有了一點兒小問題。

4、認證中心的抉擇

當前我們的角色信息是用的id，那認證中心就不能使用第二種方案了：

[Authorize(Roles = "AdminTest")]

因為這個時候，我們claims聲明中，獲取到的不是name，所以一定會失敗，就算當前用戶的角色真的是AdminTest，還是會失敗：

這是因為按照這種方案，它只認識role這個節點，但是這個節點是id，沒辦法，我們只能這么寫了：

雖然是通過了，但是看著還是感覺很不舒服，有點兒Bad Smell的意思。

所以這也就是我文章開頭說的，我為啥要新建了一個策略，使用rolename節點作為策略的原因了：

protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,ClaimRequirement requirement){var claim = context.User.Claims.FirstOrDefault(c => c.Type == requirement.ClaimName);if (claim != null && claim.Value.Contains(requirement.ClaimValue)){context.Succeed(requirement);}return Task.CompletedTask;}

5、總結

今天雖然講的是認證中心的加權處理，但是我們也要考慮到資源服務器的業務邏輯，

最終我還是采用的是：

資源服務器用roleid來配合菜單和接口id，實現權限分配；

認證中心采用策略方案，通過rolename來對頁面進行權限控制；

到此結束，Ids4實戰也告一段落了，很有意思也很能鍛煉人思維邏輯的一個框架，建議大家好好學習，不可中途放棄，加油。

總結

以上是生活随笔為你收集整理的【实战 Ids4】║ 认证中心之内部加权的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。