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

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

后台产品同学在设计后台时，会发现一般后台的各个功能模块总结起来有两大类型：功能类、流程类。在设计功能或流程前都需要预判不同的使用角色对应不同权限，设计流程前则还得思考最基本的工作流原理。
用户权限是设计后台普适的基本管理功能，设计系统时几乎都需要考虑权限问题。后台系统在面对不同部门不同岗位的人员时，如何区分授权？在考虑前端不同身份的用户访问时（如普通用户、普通会员、超级会员），如何自动判断权限？工作流则是设计流程需要具备的基本理论，一个完整的流程会会包含哪些节点动作？节点是否可自主配置？
本文主要总结后台设计的基石：RBAC和workflow。

RBAC

1、什么是RBAC

RBAC（Role-Based Access Control）基于角色的访问控制。这是从传统的权限模型基础上，改进而来并且相当成熟的权限模型。这里强调三个要素：用户、角色、权限。用户与角色是多对多关系，角色与权限是多对多关系。
传统模型中无角色概念，直接为用户赋上权限，一是导致配置权限相当麻烦，二来无法快速为多个用户批量删除权限。用户—角色—权限多对多的关系，解决了这些问题。
关键元素：

• 用户： 成功认证并登录系统的操作员（主体：who）
• 权限： 访问资源的许可（how）
• 角色： 权限的集合体
• 资源： 引入这第四个概念，包括系统菜单、页面、按钮等（what）

主体（who）如何通过权限（how）访问资源(what resource)。
权限是用来访问资源的，为用户赋予权限，则可访问资源；在权限基础上，将权限打包为一个权限集合—角色，如财务经理角色，则为用户赋上财务经理角色，用户可访问财务经理角色下的资源集合。

2、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的集合体。即支持角色间的继承关系，又支持角色间的责任分离关系。一般无需如此全面负责的模型。

3、关于一般角色、数据角色、成员角色

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

• 一般角色： 可见功能菜单页、功能操作按钮、数据字段，均可通过颗粒度较细的权限，去组合成一般角色。
• 数据角色： 指可查询的数据范围。同一个一般角色，如查看客户数据，大区总监能看到整个大区的数据，上海分公司经理只能看到上海客户数据。上级组织职能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。
• 成员角色： 新建成员即自动赋予的角色，即普通用户均有的常规权限，无需再手动配置。

4、常见的常规管理功能

（1）用户管理
用户按架构新建在对应的组织上。一般挂到机构→部门（一级部门–二级部门）下。
对于公司内部管理系统，管理用户的前提，是需要合理的组织架构，只有支持组织架构的灵活配置，才能进一步支持组织内人员的增删调整。
（2）角色管理
所有角色的管理功能。新建角色时，可将角色建立在某级机构或机构及以下，代表此角色只能适用此级别或此级别以下级别。
（3）菜单管理（有的后台叫栏目管理）
支持自主配置菜单一级二级，支持新增菜单、修改菜单、删除菜单，更改菜单（修改菜单名、菜单顺序等），每个菜单对应一个权限。
（4）组管理
用户所属组，用于配置统一组同一部门用户。有了用户组，在新建角色时，可直接将角色赋予某个组，则进入此组的人员自动获得对应角色。

workflow

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

1、工作流常见的路由方式

（1）串行路由
按顺序一个步骤接着一个步骤走流程：

案例：入职流程，人力专员提交——HRBP审批——人力总监审批，顺序走完流程。
（2）并行路由
同时可以执行多个不同的节点：

（3）条件路由
满足条件后导向一个节点，不满足条件的导向另外一个节点。

案例：流程提交满足XX模式，则走A节点，不满足则走B节点。
（4）分支路由
分支路由平行分支出多条线路，多条线路之间是并行的关系。
案例：付款申请，提交后判断，对公付款走对公审批，对私付款走对私审批。
（5）合并路由
并行的多路分支集结到一个点的路由方式，前序分支节点全部都经过处理，最终才到汇合节点处理

案例：多个申请项目，同一天提交到终审岗审批。
（6）循环路由
下一步返回到原来的任意一个步骤，这之间形成的回路就是一个循环路由。

案例：发起的流程，条到某岗位后，再流转到自己确认，再提交。
（7）自由跳转
这种是很特殊的路由方式，在流程实际运行时跳出原来定义的线路，自由跳转到任意的步骤。

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

2、常见节点动作

• 提交： 每个节点的人将流程提交至下手岗位。
• 回退： 可退回到某个节点继续流转，退回到发起岗，或退回到前手岗。
• 撤回： 节点执行完后、下一节点执行前，可以收回进行修改然后再提交。
• 取消/撤销： 流程发起人执行取消流程。
• 中止： 流程提前结束，当前节点之后的其它节点不再执行。
• 审批： 表单中的某个字段，用于填写审批意见。
• 会签： 通常用于审批后给相关的人签字确认，需要签字确认。
• 知会： 指定的人知道有这个流程这么回事，并能查看流程，不需要签字确认。
• 加签： 审批时，可以征求另一人或多人的意见，然后再回到原审批人。
• 跳签： 跳过接下来的一个或连续的多个节点，直接到指定的节点执行。
• ……

3、上报关系

每个节点提交后，下一节点将有谁审批？一般会为对应岗位的人员配置对应的节点。但若涉及到分公司或分地区审批，则需要设计上报关系。
上报关系支持灵活配置前一岗与后一岗的对应关系。如北京分公司的审批，提交到财务审核时，只能提交到北京财务部。合作公司的审批，只能提交到综合财务部。此时就需要提前配置上报关系，北京分公司——北京财务部；合作公司—-综合财务部。各个部门均可配置对应上报关系，包括财务，人力，业务等。
最后，为用户配置某个财务部的权限，则其仅可接收特定对应的上报关系的审批申请。如权限为综合财务部用户，仅可收到合作公司提交的申请单。
BRAC和流程节点，在设计过程中，还需考虑其灵活性。
如操作员入职流程完毕后，自动赋予其岗位对应角色权限，当然这可通过对用户组分配角色实现。当操作员调岗时，根据调岗的跨度大小，自主确定是否更改权限或删除权限。流程节点在系统中可根据对应业务，后台预备支撑性较强的节点变量，支持前台配置，由管理员自主根据对应业务流程，配置相应的流转节点。
 
作者：柴小英，先后混迹于大数据及互金领域，负责过资金端理财平台及资产端信贷后台，现任银客集团资产端产品经理

关键字：工作流模型, 用户权限管理, 角色, 权限

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！