基于资源的权限系统-设计思路
概述
权限系统提的最多的就是 RBAC（基于角色的访问控制）。 所谓角色，其实就是权限的集合，某个角色就是某几个权限的结合。其目的是为了简化授权和鉴权的过程。
基于角色的权限控制用在简单的权限环境下没有问题，如果在权限控制比较复杂的系统中，或者说要做通用的权限系统时，基于角色的权限控制会带来以下问题：
角色可以用来做功能权限，做数据权限的话，会导致角色数量非常多 比如：bug管理系统，一般有 developer, reporter, manager 等一些角色，其中，reporter 可以创建bug，developer 可以解决，回复bug，manager 可以统计bug 等等。 在这个系统中，通过设置 developer，reporter，manager 几个角色，可以使得授权，鉴权更加简单，直观。 但是，如果权限粒度要求更细的话，比如，某些reporter只能创建普通级别的bug，某些reporter可以创建各个级别的bug，或者有更加细粒度的权限要求的话，角色的数量就会激增。 到时候，管理角色本身带来的工作量反而会大于角色带来的好处。
角色是一维的，不同的角色之间一般都是独立的，而人员之间一般有树状的组织关系。所以，角色就很难与已有的组织关系互相映射。 而授权的时候，经常是上级的组织会自动获取下级创建的数据的一些权限
对于不确定的系统来说，角色不好定义。如果是bug系统，比较成熟，方便定义角色类型，如果是通用系统的话，用户其实不太容易定义好自己需要的角色。
另一种 RBAC（resource base access control）
基于角色的权限系统一般简称 RBAC，而这里的 RBAC 是指 基于资源的权限系统。
设计思路
目的是设计一种通用的权限管理系统，不和任何的实际的业务关联，只做权限相关的管理和验证。 之所以以 资源 为核心，是因为上面的提到的那些基于 角色 的限制。 基于资源的权限系统是围绕 组织树 和 资源树 来进行权限的。
术语介绍
- 人员 : 实际使用系统的用户，也就是需要进行权限检查的人
- 组织 : 树形结构，但是人员可以属于一个或者多个组织
- 资源 : 需要授权的东西都可以认为是资源，每个功能是资源，每个接口也是资源，每条数据也是资源。 资源树 上的根就是整个系统。
- 动作 : 对资源的操作，比如常用的 创建，删除，更新，查询
- 权限 : 组织 + 资源 + 动作 （什么人对什么资源可以做什么动作）
系统初始化
权限系统本身提供一个超级用户(admin)，通过此用户来初始化最初需要的信息。
初始信息只需要定义：
- 组织的根节点：以后追加的所有人员和组织都在此节点之下（比如就是某个公司）
- 资源的根节点：以后追加的所有资源都在此节点之下（比如就是需要进行权限控制的系统）
- 动作：对资源可能进行的操作（一般就是CURD，增删改查）
有了以上信息，就完成了针对某个系统和组织的权限系统的基本初始化。 基本信息初始化之后，可以导入组织/人员，以及资源信息，或者直接在权限系统提供的页面上操作。
注意 每个资源只有一个父节点，每个组织也只有一个父组织，但是每个人员可以属于多个组织。
授权过程
授权是权限系统中重要的步骤之一，另一个重要步骤就是鉴权。 授权有2种视图：
人员/组织 视图 下的授权流程
- 选择 资源
- 选择 动作
- 确认授权
- 生成权限数据
注1 前2步的选择都可以多选。
资源 视图 下的授权流程
- 选择 人员/组织
- 选择 动作
- 确认授权
- 生成权限数据
鉴权过程
鉴权是使用最频繁的步骤，几乎每次请求都会有鉴权的操作。 鉴权就是判断 某人对某资源做某个动作 是否合法，所以鉴权的 input 是 人员/组织，资源，动作； output 则是是否鉴权成功。
- 根据 input 的内容（人员/组织，资源，动作），查看权限表中是否有匹配的数据
- 1.1 有匹配的数据，返回鉴权成功
- 1.2 没有匹配的数据，查找 人员/组织 所属的父组织，再次用 （父组织，资源，动作）作为 input，查看权限表中是否有匹配的数据
- 1.2.1 有匹配的数据，返回鉴权成功
- 1.2.2 没有匹配的数据
- 1.2.2.1 当前组织已经是 根组织，返回鉴权失败
- 1.2.2.2 当前组织不是 根组织，进入步骤 1.2
自动授权规则
对功能权限来说，一般数据量不会太大，即使没有自动授权，手动授权也可以完成。 但是对数据权限来说，不仅数据量庞大，而且如何授权也不确定，数据的变化也可能会很频繁，手动来做几乎不可能。
自动授权目的是将自动授权机制参数化，让用户通过设置不同的参数来生成不同的权限数据。 自动授权机制是以插件的形式加入到权限系统中的，默认可以提供几种常用的自动授权机制插件。 在授权时，也可以指定使用一种或者多种自动授权插件。
下面以一个示例来说明插件是如何使用的。 示例插件：创建数据时自动授权插件 功能：用户A 创建数据X 后，生成如下权限数据：
- 用户A 可以 修改 查询 删除 数据X
- 用户A 所属组织的成员可以 查询 修改 数据X
- 其他组织的成员可以 查询 数据X
此插件参数就是3个list：自己的动作列表，同组织成员的动作列表，其他组织人员的动作列表 插件的参数是在权限系统中的插件管理功能中配置的（插件参数的设置需要用到动态表单，因为插件的参数个数，类型等都是不定的）
使用流程如下：
- 某用户创建了一条数据
- 创建完数据后，调用权限系统的授权接口，在授权接口中指定使用上面的 示例插件
- 权限系统的授权接口会调用上面的 示例插件 给用户，用户所属组织以及其他组织 分别授予相应的权限
针对不同类型的系统，授权方式千差万别，将授权的实现剥离出来，是为了增加系统的通用性。
总结
通用权限管理的主要的功能就是 授权 和 鉴权 ，其本质都是对权限数据（什么人对什么资源可以做什么动作）的管理。 授权的难点在于给某人授与某个数据的权限之后，组织中其他关联人员可以计算出自己对这个数据的权限，这就是自动授权插件的意义。 鉴权的难点一是权限的数据量会比较大（如果权限粒度细的话），一是有些权限是需要计算的。
基于角色的权限系统的核心在 角色（人员），而基于资源的权限系统核心在 资源，资源是权限系统需要保护的东西。 希望能从资源的角度来设计出更加通用的权限管理系统。