📚 课程目录第3章权限控制基础模型

3. 权限控制基础模型：RBAC（基于角色的访问控制）模型在审批流中的应用

在采购合同审批流中，权限控制的核心目标是确保“正确的人，在正确的节点，执行正确的操作”。RBAC（Role-Based Access Control，基于角色的访问控制） 是目前企业级BPM系统中应用最广泛的权限模型。它将权限与角色关联，再通过为用户分配角色来授予权限，从而实现了用户与权限的逻辑分离，极大简化了权限管理复杂度。

3.1 RBAC 核心三要素

RBAC 模型围绕三个核心实体构建：用户（User）、角色（Role）、权限（Permission）。在审批流场景中，权限具体表现为对某个审批节点的“操作权”（如审批、驳回、转办、查看）以及对合同数据的“访问权”（如查看金额、查看供应商信息）。

要素	定义	审批流示例
用户（User）	系统的操作主体，即具体的人或系统账号。	张三（采购员）、李四（财务经理）、王五（法务专员）
角色（Role）	组织内职责或岗位的抽象集合，是权限分配的中间层。	采购专员、财务审批岗、法务审核岗、副总裁
权限（Permission）	对系统资源或功能的具体操作许可。	“审批采购合同（金额≤50万）”、“驳回并退回上一节点”、“查看合同附件”

  关键设计原则： 用户与权限不直接关联。用户通过“角色”间接获得权限。当员工岗位变动时，只需调整其角色，无需逐一修改其权限。

3.2 角色与权限的映射关系

在审批流参数配置中，角色与权限的映射不是简单的“一对一”，而是通过多对多关系构建出灵活的授权矩阵。一个角色可以拥有多个权限，一个权限也可以被多个角色共享。下图展示了采购合同审批流中典型的角色-权限映射关系。

配置要点： 在BPM流程设计器中，通常通过“角色选择器”组件来配置审批节点。系统运行时，会根据当前用户的角色自动匹配其拥有的操作权限。例如，当合同金额超过50万时，只有“副总裁”角色才拥有“审批（＞50万）”权限。

3.3 RBAC 在审批流中的三种授权模式

根据企业组织复杂度和审批粒度要求，RBAC 在采购合同审批流中通常表现为以下三种模式：

静态角色授权（Static Role Assignment）：用户入职时被固定分配一个或多个角色，角色权限相对稳定。适用于岗位职责明确的部门，如“法务审核岗”固定拥有“法务合规审查”权限。
动态角色授权（Dynamic Role Assignment）：用户在执行审批任务时，根据上下文条件（如部门、金额、项目类型）临时获得某个角色。例如，当合同属于“IT设备采购”时，系统自动将“IT总监”角色赋予审批节点。
层级角色授权（Hierarchical Role Assignment）：角色之间存在继承关系，上级角色自动拥有下级角色的所有权限。例如，“副总裁”角色继承“财务审批岗”和“法务审核岗”的权限，实现审批流的向上汇总。

授权模式	适用场景	配置复杂度	灵活性
静态角色授权	固定岗位审批（如采购专员发起）	低	低
动态角色授权	按合同属性分流（如金额、品类）	中	高
层级角色授权	多级审批链（如部门→总监→VP）	中高	中

3.4 权限控制粒度：从功能到数据

在审批流参数配置中，权限控制不仅限于“能否审批”这种功能级权限，还需要深入到数据级权限。RBAC 模型可以扩展为以下两个维度：

功能权限（Function Permission）：控制用户能否访问某个功能按钮或页面。例如，“驳回”按钮仅对“财务审批岗”和“法务审核岗”可见。
数据权限（Data Permission）：控制用户能查看或操作哪些数据行或字段。例如，“采购专员”只能查看自己发起的合同，而“副总裁”可以查看所有合同。

常见配置陷阱： 仅配置功能权限而忽略数据权限，会导致用户虽然无法操作审批，但可以越权查看敏感合同信息（如供应商报价、折扣条款）。在配置RBAC时，必须同时定义“行级数据过滤规则”。

3.5 RBAC 模型在审批流中的参数配置示例

以下是一个基于RBAC的采购合同审批节点参数配置示例（伪代码），展示了角色与权限的映射关系如何在BPM引擎中落地：

// 审批节点配置：财务审批
{
  "nodeId": "finance_approval",
  "nodeName": "财务审批",
  "assignee": {
    "type": "role",
    "roleId": "finance_approver",
    "dynamicFilter": {
      "field": "contractAmount",
      "operator": "<=",
      "value": 500000
    }
  },
  "permissions": [
    {
      "action": "approve",
      "allowedRoles": ["finance_approver", "vp"]
    },
    {
      "action": "reject",
      "allowedRoles": ["finance_approver"]
    },
    {
      "action": "view_attachment",
      "allowedRoles": ["finance_approver", "legal_reviewer", "vp"]
    }
  ],
  "dataPermission": {
    "filter": "department == currentUser.department || currentUser.role == 'vp'"
  }
}

上述配置中：

assignee 指定了该节点的处理人角色为 finance_approver，且仅当合同金额≤50万时生效。
permissions 定义了不同角色在该节点上的操作权限：approve 权限由财务审批岗和副总裁共享；reject 权限仅限财务审批岗。
dataPermission 实现了数据级隔离：普通财务人员只能看到本部门的合同，而副总裁可以看到全部。

  最佳实践： 在配置RBAC时，建议将角色定义与权限定义分离管理。角色由组织管理员维护，权限由流程架构师在BPM设计器中配置。这样当组织架构调整时，只需修改角色-用户映射，无需重新部署审批流。

3.6 本章小结

RBAC 模型通过引入“角色”这一中间层，实现了用户与权限的解耦，是采购合同审批流权限控制的基础。在实际配置中，需要重点关注：

角色与权限的多对多映射关系，确保权限分配的灵活性。
根据业务复杂度选择静态、动态或层级授权模式。
同时配置功能权限与数据权限，防止越权访问。
通过参数化配置（如金额阈值、部门过滤）实现权限的自动化控制。