【实战 Ids4】║ 认证中心之内部加权

本期配套视频：

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

（昔我往矣，杨柳依依，今我来思，雨雪霏霏）

我们知道，认证中心的作用就是用来保护我们的资源服务器，所以说认证中心是一个保护者，当然，他在保护其他客户端的时候，也需要对自己进行保护，举例来说：

我的Ids4项目中，有用户角色信息管理，客户端数据管理等等，这些不可能让普通的登录用来来访问的

因此我们同样需要在认证中心内部实现加权处理，用来保护某些页面或者说某些数据的安全性不被恶意攻击或访问。

当然除了不让普通用户访问，我们也同样为了区分公司内部管理员的身份和权限，也同样需要如此，超级管理员有很高的权限，可以处理任意数据。

这就是为什么我们需要在认证中心内部进行权限管理的原因。

这个问题不仅仅是在认证中心，其实在任何的项目中，包括资源服务器中，我们也是常用这几种权限处理方式，多数是基于角色控制的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角色名，判断各自的角色，那我为啥不直接用第二种呢：

这样岂不是更简单，也不用写处理器等逻辑了，直接这么写一下即可。

下边我会讲为什么没有用这个。

你可能会好奇，今天说的是认证中心的加权，为啥又说到了资源服务器？是不是多此一举了，并不是，其实我们写的每一行代码都应该考虑下，是否对其他的有影响，是否对其他的项目有关联，今天说的认证中心也是，我先给大家回忆一下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是先开发的，所以假设我们的这个资源服务器代码不改的话，认证中心就有了一点儿小问题。

[Authorize(Roles = "AdminTest")]

 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; }