后台设计基石：用户权限管理（RBAC）及工作流（workflow）

Posted 2021-05-01 郎怼怼

后台产品同学在设计后台时，会发现一般后台的各个功能模块总结起来有两大类型：功能类、流程类。在设计功能或流程前都需要预判不同的使用角色对应不同权限，设计流程前则还得思考最基本的工作流原理。

用户权限是设计后台普适的基本管理功能，设计系统时几乎都需要考虑权限问题。后台系统在面对不同部门不同岗位的人员时，如何区分授权？在考虑前端不同身份的用户访问时（如普通用户、普通会员、超级会员），如何自动判断权限？工作流则是设计流程需要具备的基本理论，一个完整的流程会包含哪些节点动作？节点是否可自主配置？

本文主要总结后台设计的基石：RBAC和workflow。

1.RBAC

RBAC（Role-Based Access Control）基于角色的访问控制。这是从传统的权限模型基础上，改进而来并且相当成熟的权限模型。这里强调三个要素：用户、角色、权限。用户与角色是多对多关系，角色与权限是多对多关系。

传统模型中无角色概念，直接为用户赋上权限，一是导致配置权限相当麻烦，二来无法快速为多个用户批量删除权限。用户—角色—权限多对多的关系，解决了这些问题。

关键元素：

用户：成功认证并登录系统的操作员（主体:who）

权限：访问资源的许可（how）

角色：权限的集合体

资源：引入这第四个概念，包括系统菜单、页面、按钮等（what）

主体（who）如何通过权限（how）访问资源(what resource)。

权限是用来访问资源的，为用户赋予权限，则可访问资源；在权限基础上，将权限打包为一个权限集合—角色，如财务经理角色，则为用户赋上财务经理角色，用户可访问财务经理角色下的资源集合。

02

RBAC模型解读

根据RBAC的复杂度不同，可分为RBAC0，RBAC1，RBAC2，RBAC3.最常用的为RBAC0.

（1）RBAC0模型

将一个或多个权限挂到角色下，在将一个或多个角色赋予用户，权限与角色的关系，角色与用户的关系，均是多对多的关系。

场景：为财务经理岗建立财务经理角色，将对账、付款审批、回款确认等权限配置在财务经理角色下，则公司再更换财务经理人员，只需每次为新来的财务经理配置财务经理角色。

为客户经理建立客户经理角色，客户管理、客户查询、抢单等权限配置在客户经理角色下，适应于公司流动性高且占比庞大（多的甚至上千人）的客户经理群体，若某个权限不适宜配置给客户经理，直接在角色中删除即可，无需分别对每个人进行权限删除。

（2）RBAC1模型

引入继承概念，一个角色可以从另一个角色继承许可权。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多继承，受限继承关系则进一步要求角色继承关系是一个树结构。

场景：适用于角色之间的层次明确，如总经理与副总经理，业务部门如总经理–团队经理–业务员。也适用于用户分级管理，初级用户只能使用部分功能，中级用户能够使用更多功能。

（3）RBAC2模型

加入了角色的访问控制。规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

包括静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic DSD(Dynamic Separation of Duty)。

互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。案例：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。

基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；一个角色的权限数目受限。案例：如VP类角色不可随意分配给多个用户。

先决条件角色 ：指要想获得较高的权限，要首先拥有低一级的权限。案例：先有副总经理，才能有总经理权限。

运行时互斥 ：例如，允许一个用户具有两个角色，但不可同时激活这两个角色。

（4）RBAC3模型

RBAC1+RBAC2的集合体。即支持角色间的继承关系，又支持角色间的责任分离关系。一般无需如此全面负责的模型。

03

一般角色、数据角色、成员角色

角色一般可拆分为一般角色、数据角色、成员角色。

一般角色：可见功能菜单页、功能操作按钮、数据字段，均可通过颗粒度较细的权限，去组合成一般角色。

数据角色：指可查询的数据范围。同一个一般角色，如查看客户数据，大区总监能看到整个大区的数据，上海分公司经理只能看到上海客户数据。上级组织职能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。

成员角色：新建成员即自动赋予的角色，即普通用户均有的常规权限，无需再手动配置。

• 
  

2.workflow

一个业务流程包含多个环节的审批确认关系，按照业务流程，将各个节点串接起来，即时工作流。系统实现各个节点的自动流转，解决手工处理工作流程的低效和失误，提高工作效率的同时，还可通过线上直接流程状况进行实时跟踪，实现业务流程流转的自动化。

01

工作流常见的路由方式

（1）串行路由

按顺序一个步骤接着一个步骤走流程：

案例：入职流程，人力专员提交——HRBP审批——人力总监审批，顺序走完流程。

（2）并行路由

同时可以执行多个不同的节点：

（3）条件路由

满足条件后导向一个节点，不满足条件的导向另外一个节点。

案例：流程提交满足XX模式，则走A节点，不满足则走B节点。

（4）分支路由

分支路由平行分支出多条线路，多条线路之间是并行的关系。

案例：付款申请，提交后判断，对公付款走对公审批，对私付款走对私审批。

（5）合并路由

并行的多路分支集结到一个点的路由方式，前序分支节点全部都经过处理，最终才到汇合节点处理

案例：多个申请项目，同一天提交到终审岗审批。

（6）循环路由

下一步返回到原来的任意一个步骤，这之间形成的回路就是一个循环路由。

案例：发起的流程，调到某岗位后，再流转到自己确认，再提交。

（7）自由跳转

这种是很特殊的路由方式，在流程实际运行时跳出原来定义的线路，自由跳转到任意的步骤。

案例：满足某个条件，则自动跳过某个岗位，无需此岗位再审批。

02

常见节点动作

提交：每个节点的人将流程提交至下手岗位。

回退：可退回到某个节点继续流转，退回到发起岗，或退回到前手岗。

撤回：节点执行完后、下一节点执行前，可以收回进行修改然后再提交。

取消/撤销：流程发起人执行取消流程。

中止：流程提前结束，当前节点之后的其它节点不再执行。

审批：表单中的某个字段，用于填写审批意见。

会签：通常用于审批后给相关的人签字确认，需要签字确认。

知会：指定的人知道有这个流程这么回事，并能查看流程，不需要签字确认。

加签：审批时，可以征求另一人或多人的意见，然后再回到原审批人。

跳签：跳过接下来的一个或连续的多个节点，直接到指定的节点执行。

……

• 
  

03

上报关系

每个节点提交后，下一节点将有谁审批？一般会为对应岗位的人员配置对应的节点。但若涉及到分公司或分地区审批，则需要设计上报关系。

上报关系支持灵活配置前一岗与后一岗的对应关系。如北京分公司的审批，提交到财务审核时，只能提交到北京财务部。合作公司的审批，只能提交到综合财务部。此时就需要提前配置上报关系，北京分公司——北京财务部；合作公司—-综合财务部。各个部门均可配置对应上报关系，包括财务，人力，业务等。

最后，为用户配置某个财务部的权限，则其仅可接收特定对应的上报关系的审批申请。如权限为综合财务部用户，仅可收到合作公司提交的申请单。

BRAC和流程节点，在设计过程中，还需考虑其灵活性。

如操作员入职流程完毕后，自动赋予其岗位对应角色权限，当然这可通过对用户组分配角色实现。当操作员调岗时，根据调岗的跨度大小，自主确定是否更改权限或删除权限。流程节点在系统中可根据对应业务，后台预备支撑性较强的节点变量，支持前台配置，由管理员自主根据对应业务流程，配置相应的流转节点。

本期依然放弃我的主业《原型故事》，原因很简单，前三篇原创其中有一篇作者名字写错了！！！结果就是，还得再补一篇，才能打开留言功功能！！！骂娘三分钟~

创新｜脑洞｜扯淡达人