X0 概述
在2B系统开发中，权限体系设计是绕不开的问题。最简单的当然是RBAC模型，只要通过用户、角色、权限几个有限的概念，就可以建立起一套基本可用的权限体系。再复杂一点，可以增加角色的层级概念，使得角色的配置更高效。
但现实工作中，权限控制的需求往往更复杂，不仅涉及到功能授权，也涉及到数据授权，有些系统甚至涉及到更细的数据颗粒度授权，这个时候RBAC模型就显示出诸多的不足。
如何设计一套简单高效的权限体系，使得能够满足各种从简单到复杂的场景的应用，是产品经理和系统架构师需要用心的基础工作
X1 核心痛点
我公司一直想做一套Saas系统，目标是服务于智慧社区的管理，里面涉及到大量的组织、人、财、物、数据的管理，其中组织和人又需要分成多个层级，比如：
- 平台公司的组织结构
- 平台公司的租户管理
- 租户公司的组织结构
- 租户公司的客户管理
- 客户公司的组织结构
- 客户公司的员工管理
等等。
如何能够灵活地设置权限，让不同性质的用户在这个Saas平台上自如地处理业务，同时又严格地限制其数据访问范围，做到安全可控，是一个很大的挑战。
其次，还需要考虑常见的情况，比如：
- 一人多岗或者多职，比如分管领导兼任部门领导
- 多角色的跨越，比如即是员工又是用户
- 相同岗位不同管辖范围授权，比如多公司会计
等等。
还有更苛刻的要求，比如需要考虑不同的岗位对同一个数据拥有不同的访问权限，比如：
- 查询字段的限制
- 编辑字段的限制
- 下载字段的限制
等等。
以上需求都对传统的RBAC权限体系设计构成了巨大挑战。
X2 新权限体系模型
本着宁简勿烦的奥卡姆剃刀原则，对于以上复杂的权限管理需求，首先可以抽象出几个必要的概念。
A. 资源(Resource)
借鉴传统的LDAP产品，我们可以把每一个需要纳入管理的组织、人、财、物、数都看成是一种资源，当然每种资源的描述内容是千差万别的。
B. 资源类型(ResourceType)
不同的资源类型对应不同的元数据，可以有不同数量和类型的字段对其进行描述。不同资源类型之间相互可以有关联关系。
根据一般性的社会需要，可以大致分为：公司、部门、个人、设备（可以再细分）、地域（可以再细分）、小区等。原则上需要拥有单独的元数据描述的资源都需要定义为一种资源类型。
C. 资源详情(ResourceProfile)
如果需要去查看资源的具体的情况，就需要根据“资源类型+资源元数据”打开资源详情，在资源详情上面可以进行各种增删查改操作。
D. 资源目录(ResourceTree)
不同资源相互之间存在层级和依赖关系，并且每个资源只有唯一的父级资源，就构成了一颗自上而下的资源目录或者资源树。资源树是我们后期进行数据权限设置和控制的基础。
E. 权限(Privilidge)
权限比较简单，可以对应系统中某个菜单入口，或者某个操作按钮，或者某类资源的增删查改操作等。
F. 角色(Role)
角色跟RBAC一样，即是一组权限的组合。角色和角色之间可以形成层级关系。
一般而言，父级角色拥有比子级角色更大的权限，子级角色的权限则是父级角色权限的子集。
G. 岗位
对一个组织（公司或部门）可以设定多个岗位，每个岗位需要定义以下内容：
- 所属组织(公司或部门)
- 角色
- 资源类型
- 该资源类型可查看字段
- 该资源类型可编辑字段
- 该资源类型可下载字段
- 该资源类型的访问池（可以是资源目录中某些节点组合，也可以是具体的资源组合）
以上定义完整，即构成一个部门的一个岗位。
H. 用户
对用户而言，首要的是能够登录认证。只要在系统的资源目录中，并且账号密码验证通过即可访问该系统。
其次是用户操作具体业务和访问具体资源的授权检查，这个就需要通过给用户配置一个或多个岗位来实现。
当用户完成登录操作后，系统应该同步获取其拥有的岗位，并且能够在系统层级做不同岗位的切换。
X3 新权限体系关系图
X4 分级授权策略
回归到Saas系统，平台如何管理租户，租户如何管理客户，客户如何管理员工？这个就需要采取分而治之的策略。简单说就是，平台只负责为租户创建账号，然后限定其功能权限和数据权限，剩下的资源目录和权限体系由其自己去管理，租户对客户的管理也是如此。
但不同类型的管理员所能创建的岗位和访问的资源必然是受限的。
这就实现了一套复杂权限管理体系的架构设计。
后续如何具体形成数据库表和业务逻辑，请等待下级......
