后台设计的基石:用户权限管理(RBAC)及工作流(workflow)模型

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

本文作者主要总结后台设计的基石: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和流程节点,在设计过程中,还需考虑其灵活性。

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

 

作者:柴小英,先后混迹于大数据及互金领域,负责过资金端理财平台及资产端信贷后台,现任银客集团资产端产品经理

本文由 @柴小英 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pixabay,基于 CC0 协议

赞赏是对原创者的最大认可
7人打赏
评论
欢迎留言交流
  1. 最近在做权限管理,觉得人和资源之间有对应关系,而且是多对多的。资源只是页面内的展示(操作)内容,完全没有必要把资源和权限建立对应关系。

    回复
  2. 如果是平台化,多机构企业入驻,在权限控制方面可否使用单一平台进行控制。如果用单一平台控制,能大体说下思路嘛

    回复
    1. SAAS平台是吧?

      回复
  3. 很好!我来挑刺哈哈,
    “先决条件角色 :指要想获得较高的权限,要首先拥有低一级的权限。案例:先有副总经理【全下】”,全下=权限吧

    回复
  4. 这个可以作为用户权限设计的一个基础思想去理解,具体设计还要根据具体业务来,不断演变组合,以达到效果,师傅领进门,修行再个人。还是要赞一下作者的👍

    回复
  5. 艺术来源于生活,我再强调一遍,艺术来源于生活,,,大家觉得对不对,,,,,

    回复
  6. 很实用,很好的总结。

    回复
  7. 你是谁?你是什么职位?你可以做什么? 人员-角色-权限 :grin:

    回复
  8. 赞!如果业务中某特殊用户的权限超出了某一角色配置的权限,而又不足以满足2个角色的权限,这个一般怎么去设计会比较好呢?

    回复
  9. 如何看用户和角色的一对一设计

    回复
  10. 把角色加个一个用户组,跟自己把权限配置给用户组不是更好,只需保留一个即可

    回复
    1. 前提是用户组内的用户会共用一批权限集合,一般在基本的RBAC0模式下,可把基本的权限打包为一个角色,授权给用户组,再针对用户组中的高级人员或特殊人员做单独的角色授权

      回复
  11. 赞👍值得转发分享

    回复
  12. 想加微信

    回复
  13. 感觉这些理论是故意在故弄玄虚,故意用一些貌似高深的词汇。。。。也没有把后台的权限管理清晰的表达出来。

    回复
  14. 谢谢分享

    回复
  15. 还是炒冷饭啊,没啥创新哇

    回复
    1. 嗯 并无创新 只是平日工作内容总结

      回复
  16. RBAC1模型的继承关系不是很理解,能否详细说说? :o

    回复
    1. 确定角色等级后,父角色自动继承子角色内的权限集合,一般改进版的还会圈定出公有权限范围可被上级继承,私有权限不可别上级继承

      回复
    2. 作者是技术出身吧,公有,私有 ,pu’blic ,private
      ;-)

      回复
    3. 文科生…以及一直做产品…

      回复