Levon's Blog

微信: L6241425

0%

接口权限模型

发表于 更新于 分类于 ， 阅读次数： Valine：
本文字数： 2.5k 阅读时长 ≈ 2 分钟

1. RBAC(角色)

目前，接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型。模型中有几个关键的术语：

  • 用户：系统接口及访问的操作者
  • 角色：具有一类相同操作权限的用户的总称
  • 权限：能够访问某接口或者做某操作的授权资格
  1. 用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。
  2. 此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，同时整个设计的容错能力也提高了很多。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/**
 * 同步api信息
 *
 * @param request 请求
 * @return {@link ResultVO}<{@link String}>
 */
@GetMapping("/api/sync")
@PreAuthorize("@ss.hasPermission('resource:api:sync')")
@ApiOperation(value = "Api资源同步", notes = "同步api信息")
public ResultVO<String> syncApiInfo(HttpServletRequest request){
   List<SysResource> sysResourceList = resourceService.syncApiInfo(request);
   resourceService.addApiList(sysResourceList);
   return ResultVO.success("同步成功");
}


/**
 * 是否有权限
 *
 * @param permission 权限
 * @return boolean
 */
public boolean hasPermission(String permission) {
    if (StringUtils.isEmpty(permission)) {
        throw new AuthException(ResultCodeEnum.UNACCESS.getCode(), ResultCodeEnum.UNACCESS.getMessage());
    }
    UserDetail user = AuthenticationContextHolder.getCurrentUser();
    log.info("PermissionService ---> hasPermission:{}", user);
    if (user.getPermissions().contains(ALL_PERMISSION)) {
        return true;
    }
    if (!user.getPermissions().contains(permission)) {
        throw new AuthException(ResultCodeEnum.UNACCESS.getCode(), ResultCodeEnum.UNACCESS.getMessage());
    }
    return true;
}

2. 其他权限模型

ACL 最简单，ABAC 最复杂，但是功能最强大，也最灵活。RBAC 则介于二者之间。

2.1 ACL（Access Control List）

用户 -> 权限

权限能直接赋予用户，例如将查看订单列表（权限）赋予某位运营人员（用户）。

但是这种模式的缺点在于，但用户量达到一定量级的时候，那么就需要对每个用户都进行一次授权操作，那么这个工作量就会相当大。

2.2 ABAC（Attribute-Based Access Control）

ABAC模型通常是基于用户的属性（如身份、地点、时间等）和资源属性（如文件类型、敏感度等）进行判断的。你甚至可以把角色理解为该用户的一个属性，这些模型之间本身就不是互斥的，最终还是为了方便管理权限而来，所以灵活使用即可。

值得注意的是，ABAC模型一般是基于已有的一些属性来进行的权限划分，而RBAC模型则是在人为重新设置了几个角色来管理权限。

应用场景

在 ABAC 权限模型下，你可以轻松地实现以下权限控制逻辑：

  1. 授权 A 具体某部门的编辑权限；
  2. 当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档；
  3. 当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档；
  4. 早上九点前禁止 A 部门的人访问 B 系统；
  5. 在除了上海以外的地方禁止以管理员身份访问 A 系统；

上述的逻辑中有几个共同点：

  • 具体到某一个而不是某一类资源；
  • 具体到某一个操作；
  • 能通过请求的上下文（如时间、地理位置、资源 Tag）动态执行策略；

如果浓缩到一句话，你可以 细粒度地授权在何种情况下对某个资源具备某个特定的权限。

3. 参考资料

给作者打赏，可以加首页微信，咨询作者相关问题！