复杂的组织关系设计

基础概念

             ┌─────────┐       ┌──────────┐        ┌─────────┐       ┌──────────┐
             │ Tenant  │       │ Organization      │ Department      │  Role    │
             └─────────┘       └──────────┘        └─────────┘       └──────────┘
                   ▲                 ▲                  ▲                 ▲
                   │                 │                  │                 │
                   │                 │                  │                 │
             ┌─────────┐       ┌──────────┐        ┌─────────┐       ┌──────────┐
             │  User   │       │   Role   │        │  User   │       │Permission│
             └─────────┘       └──────────┘        └─────────┘       └──────────┘

在这个示例中，ER图显示了以下实体和它们之间的关系：

• Tenant（租户）：表示整个租户，具有唯一的标识符。
• Organization（组织）：属于租户的组织，每个组织具有唯一的标识符，并与租户建立关联。
• Department（部门）：属于组织的部门，每个部门具有唯一的标识符，并与组织建立关联。
• Role（角色）：定义了不同的角色，如管理员、经理、主管和普通员工等，每个角色具有唯一的标识符。
• User（用户）：系统中的用户，每个用户具有唯一的标识符，并与角色和部门建立关联。
• Permission（权限）：定义了各种操作和资源的权限，每个权限具有唯一的标识符，并与角色建立关联。

关系示例：

• 租户（Tenant）与组织（Organization）之间存在一对多关系，一个租户可以拥有多个组织。
• 组织（Organization）与部门（Department）之间存在一对多关系，一个组织可以拥有多个部门。
• 部门（Department）与用户（User）之间存在一对多关系，一个部门可以拥有多个用户。
• 用户（User）与角色（Role）之间存在多对多关系，一个用户可以拥有多个角色，一个角色也可以分配给多个用户。
• 角色（Role）与权限（Permission）之间存在多对多关系，一个角色可以拥有多个权限，一个权限也可以被分配给多个角色。

需求描述

假设需要设计一个 SaaS 系统，它内部组织架构包含了租户、组织、部门、角色和用户等实体，以及权限实体

下面对这些名称进行定义：

• 租户（Tenant）：它主要是为了隔离不同的客户的数据，每个租户都有自己的组织架构。
• 组织（Organization）：它是租户下的一个组织，每个组织都有自己的部门、角色和用户等实体。同时组织下面还有子组织，即体现为树形关系
• 部门（Department）：它是组织下的一个部门，每个部门都有自己的角色和用户等实体。同时部门下面还有子部门，即体现为树形关系
• 一级部门（Top Department）：它是最顶层的部门，即表现为 ParentId 为 0 的部门
• 一级组织（Top Organization）：它是最顶层的组织，即表现为 ParentId 为 0 的组织

这里的难点在于如何去设计它们的权限点

资源侧设计

资源的定义是：资源是系统中的一切可以被访问的对象，比如菜单、功能（按钮和接口）、数据等等

为资源添加标签管理，可以把资源类型、资源名称、资源 ID 等信息作为标签，然后把标签和权限点进行关联，这样就可以实现资源的动态管理了

• 权限模块设计

权限控制模型

DAC

自主访问控制（DAC：Discretionary Access Control）

系统会识别用户，然后根据被操作对象（object）的权限控制列表（ACL：Access Control List）或者权限控制矩阵（ACL：Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。

DAC 最大缺陷就是所有用户的权限不能统一管理，用户和用户的权限比较分散，后期调整只能单个进行调整，不易维护。

MAC

强制访问控制（MAC：Mandatory Access Control）

在 MAC 的设计中，每一个对象都都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制且无法回避的。强制访问控制多应用于对安全性要求比较高的系统，如多级安全军事系统；

RBAC

基于角色的访问控制（RBAC：Role-Based Access Control）

RBAC 是我们当前使用范围最广的一种权限设计模型，模型基础就是用户和角色，角色和权限做多对多的对应。标准的 RBAC 模型包括四个部件模型，分别为基本模型 RABC0、角色分级模型RABC1、角色限制模型 RABC2、统一模型 RABC3。

1. RBAC0（基本模型）定义了完全支持RBAC概念的任何系统的最低需求。RBAC0的模型中包括用户（U）、角色（R）和许可权（P）等3类实体集合，RABC0是权限管理的核心部分，其他的版本都是建立在0的基础上。
2. RBAC1（角色分级模型）基于 RBAC0 模型，引入角色间的继承关系，即角色上有了上下级的区别，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种模型合适于角色之间的层次明确，包含明确。
3. RBAC2（角色限制模型）引入了角色间的约束关系，主要约束规则包括：角色间的互斥关系，在处理用户和这些角色之间的关系时，包括静态分离和动态分离，静态分离指互斥的角色不能同时赋予同一个用户；动态分离指用户不能同时操作两个互斥的角色进行登录。
4. RBAC3（统一模型）同时包含了 1 和 2 的特性。

如图所示，每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而可以实现了非常灵活的权限管理。角色可以根据实际业务需求灵活创建，这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。

简单来说RBAC就是：用户关联角色，角色关联权限。并且在产品和数据设计层面，有更好的扩展性，可控制到任意的粒度。

References

• 总结：SAAS后台权限设计案例分析
• 权限模块设计