B端产品权限设计(一)基本知识

背景:每个系统都会设计权限管理,尤其对于B端产品来说,会涉及多个角色用户来使用产品,包括后台系统、移动端业务应用等。B端产品权限设计分为两个模块,包括基础知识的学习和项目中的实际应用。

一、基础知识

二、权限设计一般流程

三、功能权限&数据权限

四、参考资料


一、基础知识

RBAC(role based access control)模型,(基于用户角色的访问控制)

二、模型的不同分类

1.基本模型RBAC0:可以引入用户组/权限组的概念

-用户

-角色

-会话:会话是动态的概念,用户必须通过会话才可以设置角色,是角色与激活的角色之间的映射关系。

-许可(操作和控制对象)

 RBAC0模型


 RBAC0模型产品关系图

2.RBAC1角色分层模型

RBAC1在RBAC0基础上角色新增继承概念。比如,销售经理/销售副经理

来源于公司团队的组织结构,将角色与组织结构进行关联达到继承角色模型的目的

-用户

-角色+继承:角色就有了上下级或者等级关系

-会话

-许可

比如:上层角色继承下层角色的全部权限且可额外赋予权限

角色的继承关系:

-树形图

-有向无环图

RBAC1模型


角色关系图


RBAC1模型 产品关系图

3.RBAC2角色限制模型

RBAC0基础上假设“约束”概念,引入静态职责分离SSD和动态职责分离DSD概念。

DSD是会话和角色之间的约束,可以动态约束用户拥有的角色,如一个用户可以拥有两个角色,运行时只能激活一个角色。

SSD:用户和角色的指派阶段加入,对用户和角色有如下约束:

-互斥角色:同一个用户在两个互斥角色中只能选择一个

-基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的

-先决条件约束:用户想要获得高级角色,首先必须拥有低级角色


RBAC2角色限制模型


RBAC2角色限制模型两种限制

4.RBAC3统一模型

它是RBAC1+RBAC2合集,用于复杂情况下对权限系统进行考虑。


RBAC3统一模型

二、权限设计一般流程

1.权限设计一般逻辑

1)抽象出对产品有诉求的的多个角色

2)依据角色的特性梳理使用场景并设计

举例:

-当角色之间的使用场景不冲突,则不需要隔离,如网易云音乐的电台和听歌功能

-当角色之间的使用场景完全不相关,流程对立时,设计完全独立的两个系统,如滴滴的司机端和用户端

-当角色和使用场景部分隔离部分通用,则引入权限管理的内容

2.权限的拆分和设计

整体思路:

产品的权限由页面、操作和数据构成。页面与操作关联,先有页面权限再分配页面权限下的对应的操作权限,如图所示

基本点:

1).权限操作是否支持前端配置:适用于有频繁变动的自定义角色权限,比如,租户体系的系统

2).每个对象中,“增删改查”各自作为一个基本单元,拆分为4个权限单元。

3).首先获取页面权限,才能够配置当前页面下的操作和数据权限

4).查看权限优先于操作权限,现有查看再有操作

5).角色和权限之间的多种关系

是/否关系

数据范围:比如,用户只可以查看自己团队的用户权限

数据边界限制(上限等):添加人员时不能超过20个

数据字段:比如,HR查看人员列表中所有的字段,其他角色仅能查看姓名和邮箱

6).表达方式:基于开发语言和技术模型进行表达,如图

权限设计表达方式

小tips注意点:

1.隐形的Admin:

超级管理员

将其赋予系统维护的工作人员

2.初始权限的赋予:游客等

3.人员管理中对自己的处理:比如,当自己为唯一管理员时,禁止编辑和删除

4.无页面权限的提示:避免用户理解为系统bug,提示“无权限”等字样

三、功能权限&数据权限

1.功能权限

1).功能的粒度

模块级>页面级>接口级(接口级别的功能权限是指哪个角色能调用哪些接口)

2).功能的优先级

优先级规律:只要分配低优先级的功能必须先分配高优先级的功能。(比如,给操作权限没给查看权限,但是按钮的操作在页面上,得先给查看权限才能进行操作)

一般优先顺序为:查看详情>查看列表>增加、删除、编辑、其他操作按钮。

3).跨模块的问题

跨模块分析的,模块A中能访问链接,链接为模块B中的内容

方法一:模块A中只可通过链接访问B模块

方法二:既有A又有B权限的人才可访问

2.数据权限

解决用户能看到多少数据量和看到什么数据的问题

1).数据权限也企业的组织结构有关系,组织架构一般分为树状和扁平状

2).节点间的数据共享方式,如图,假设已经拥有功能权限


节点之间数据共享方式

目前节点间的数据共享方式类别:

-父节点可以管理所有子节点的数据

-子阶段可以管理父阶段的功能

-兄弟节点之间可以互相管理

-节点只能管理自己所在节点的数据

-节点里的用户只能看到自己的数据

实际应用时,可选择一种或者几种规则;可跟进业务定义管理:增删改查及各种小功能的组合

ps:数据权限定义过程中如果出现同一节点下【用户间层级问题(上下级)】需要回归功能权限的【角色定义】去解决。

3.角色权限系统配置

将数据权限、功能权限糅合到角色里,再行分配给用户

从用户操作层面看,选择角色的过程中完成了功能权限的配置,数据权限早已随着他的所属结点确定。

从架构设计层面看,一开始是分开设计的,一般先做功能权限,最后会数据和功能结合看。但没有既定的规则,想清楚就好。


参考资料:

-RBAC模型介绍链接https://www.jianshu.com/p/115938c6294e

-竞品:厂商SalesForce的CRM 产品Sales Cloud,遵循RBAC模型,实现了用户、角色、权限组的管理。

-权限管理:带着枷锁跳舞http://www.woshipm.com/pd/1241578.html

-RBAC权限管理模型:基本模型及角色模型解析及举例http://www.woshipm.com/pd/440765.html

-角色权限设计的100种解法http://www.woshipm.com/pd/1214616.html

-3种权限模型,快速定位设计目标http://www.woshipm.com/ucd/1036860.html(待看懂

-最好的权限设计,是先区分功能权限和数据权限http://www.woshipm.com/pd/2889402.html

-如何设计网站权限系统?https://www.zhihu.com/question/20313385

-为啥别人家SaaS就是好用——权限体系设计实战分析https://zhuanlan.zhihu.com/p/56410233

-权限管理平台的产品设计思路http://www.woshipm.com/pd/2979056.html

你可能感兴趣的:(B端产品权限设计(一)基本知识)