大型Saas系统的权限体系设计(一)

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系统，平台如何管理租户，租户如何管理客户，客户如何管理员工？这个就需要采取分而治之的战略。简单说就是，平台只负责为租户创建账号，然后限定其功能权限和数据权限，剩下的资源目录和权限体系由其自己去管理，租户对客户的管理也是如此。
但不同类型的管理员所能创建的岗位和访问的资源必然是受限的。
这就实现了一套复杂权限管理体系的架构设计。
后续如何详细形成数据库表和业务逻辑，请等待下级......