锐智互动软件开发公司
400-1050-360
软件开发 APP开发 微信/小程序开发 大型电商平台开发 数据挖掘
400-1050-360
软件开发 APP开发 微信/小程序开发 大型电商平台开发 数据挖掘

软件开发公司 > 动态 > 行业资讯

大合集:功能权限设计的那些事-软件开发 APP开发 软件开发公司 APP开发公司

行业资讯 - 2019 - 04 - 19 权限设计 功能需求 软件开发

软件开发APP开发 软件开发公司 APP开发公司

本文会通过三部分对权限设计进行描述,第一部分是理论部分;第二部分会通过几个故事对RABC模型包括的四个主要部件模型进行说明;第三部分为常见问题的汇总及相应的解决办法。

imgs/rzhd/ueditor/jpg15556459862896271.jpg

由于业务需要,最近接触到了关于权限设计的一些东西,也就有了自己的一些总结和思考,在此和大家进行探讨。

一、名词解释

在开始介绍相关理论之前,先解释下本文会用到的一些名词:

  1. 用户:指使用产品的人,有的地方也叫主体;

  2. 权限:是指在特定的情况下的一个或一组操作,如某司内部系统的人员管理中,增加人员;

  3. 权限组:一组权限的集合;

  4. 角色:权限集合的概念,如信息管理员;

  5. 角色组:一组角色的集合,如信息管理员1和信息管理员2集合为管理员;

  6. 资源:资源和权限比较难以区分,在此举例子说明,如某司内部系统的人员管理页面;

  7. 属性:属性和属性值相对应,如信息管理员访问人员管理,属性值为:1(是),˙这个例子中,“访问人员管理”为属性,1为属性值;

  8. 主体:通常指用户,是访问操作的主动发起者,它是系统中信息流的启动者,可以使信息流在实体之间流动。

  9. 客体:通常是指信息的载体或从其他主体或客体接收信息的实体。

二、常见的权限控制模型

权限设计,相对于其他的功能设计,有更为成熟的可借鉴的模型,各位可根据产品业务的需要进行采用,也可对某一个模型进行简化或者延伸。关于理论部分的资料整理于维基百科。
1. 自主访问控制(DAC)

核心为用户可将自己拥有的权限分配给其他人。

优点:用户可根据需要自行分配自己的权限。

缺点:所有用户的权限不能统一管理,用户和用户的权限比较分散,后期调整只能单个进行调整,不易维护

2. 强制访问控制(MAC)

通过无法回避的访问限制来阻止直接或间接地非法入侵。如主体和客体都有固定的安全属性,在每次访问发生时,系统检测安全属性以便确定一个用户是否有权访问该文件。当用户的安全属性值大于等于客体的安全属性值时,客体就可以被访问。强制访问控制多应用于对安全性要求比较高的系统,如多级安全军事系统;

3. 基于角色的权限管理(RBAC)

这个模型我们见的会比较多,模型基础就是用户和角色,角色和权限做多对多的对应。标准的RBAC模型包括四个部件模型,分别为基本模型RABC0、角色分级模型RABC1、角色限制模型RABC2、统一模型RABC3。

RABC1(角色分级模型)为引入角色间的继承关系,角色继承分为一般继承关系、受限继承关系,相较于一般继承关系,受限继承关系要求角色继承关系是一个树结构。

RABC2(角色限制模型)引入了角色间的约束关系,主要约束规则包括:角色间的互斥关系,在处理用户和这些角色之间的关系时,包括静态分离和动态分离,静态分离指互斥的角色不能同时赋予同一个用户;动态分离指用户不能同时操作两个互斥的角色进行登录。

RABC3(统一模型)同时包含了1和2的特性。

优点:在产品和数据设计层面,有更好的扩展性,可控制到任意的粒度。

4. 基于属性的访问控制(ABAC)

这个模型我研究了半天,才稍微明白一些。这里只能浅显的描述一下模型理论:

主体访问客体时,自己是带有属性的,例如自己的角色、职位等;客体本身也是有属性的,如角色、区域,主体在访问客体时,通过第三方属性策略,判断主体的具体权限。

小结:以上描述了在本系列中会用到的关键性词汇,接着描述了常见的一些权限控制的基本模型,通过对权限设计基础理论的理解,掌握用户、权限、角色的理论精髓,根据产品业务的需要是可以延伸出来很多不同的权限控制模型的。

三、背景

主角为某公司内部信息平台。在该平台内可对公司人员和客户进行管理,包括增删改查。

涉及到的用户包括小明、小红、铁蛋、钢蛋、Lucy、Lily、用户1、用户2…用户6,用户7,各用户对应的岗位和权限如表1.1.1。

表1.1.1 用户权限表


imgs/rzhd/ueditor/jpg15556460294658742.jpg



四、RBAC四个部件

了解了故事背景后,开始正文,在接下来的内容中,会通过四个故事,对RBAC的四个部件模型的使用进行说明。首先是基础模型RABC0。

1. 基本模型:RBAC0

故事1:目前公司规模只有十几个人,一天老板把我叫过去说,涉及到数据的私密性,希望可以对每个职员的权限进行控制。

这种情境下,我们可以用最基本的RABC0模型来进行设计,主要分为以下三步:

第一步,抽取角色,确定用户和角色的关系;

这里的角色主要是指在组织内承担特定的业务活动,并和别的业务角色进行交互的业务角色。业务角色的抽取主要有两种方式,一种是直接和岗位对应,另外一种是根据流程的本质和需要定义角色;由于故事及故事背景均不涉及到具体的流程,所以这里根据用户的权限共同性,进行角色的定义和抽取,见表2.1。

第二步,确定各角色的用例图,见图2.1.1;

第三步,根据业务复杂度、用户特点进行原型草图设计,见图2.1.2;

表2.1.1 用户、角色的对应关系




图2.1.1 角色用例图


imgs/rzhd/ueditor/jpg15556461516107767.jpg


图2.1.2 增加角色和用户的原型

使用此模型时,我们需要注意的问题有:

  1. 用户和角色为多对一的关系,如果需要用到多对多的关系,将涉及到角色关系的处理,此种情况会在故事3中进行说明;

  2. 权限一定是动态可配置的,不是静态的,这点一定要在着手开发前进行说明,一般情况,权限的数据结构为树形,合理的数据结构,便于前端根据实际需求进行解析;

  3. 视图和数据是绑定的,所以前端对数据的解析主要看视图、交互的设计;

2. 角色分级模型:RBAC1

故事2:一天老板又把我叫到办公室,语重心长的说,这个小王呀,管理平台设置权限的同事反馈,一个个的角色设置好麻烦啊,能不能上级直接拥有下级的权限啊,比如人事主管直接拥有下属所有员工拥有的权限?

这种场景下,可以使用角色分级模型。在理论篇中,我们提到过,分级模型引入了角色间继承关系,分为一般继承和受限继承。

一般继承关系只要求角色继承关系为绝对偏序关系,允许角色间的多继承。这里绝对偏序关系是指角色间继承关系为非闭环。而受限继承进一步要求角色继承关系为树结构。

基于RBAC1进行权限的设计,相比RBAC0,需要设计角色间层级关系和角色间继承关系。RBAC1两种继承关系的差别主要为继承关系的不同,详见第二步中的角色继承关系图。

第一步,抽取业务角色,确定角色和用户间关系;

同故事1不同,因为要求角色间有明显的层级关系,所以在没有其他需求的情况下,此故事背景下根据业务部门和岗位进行角色的抽取,见表2.2.1;

第二步,确定角色之间的层级关系和继承关系;

我们使用树形和非闭环网图来表示角色之间的层级关系,见图2.2.1、图2.2.2和图2.2.3;

第三步,进行原型草图的设计;

草图包括增加角色、增加人员和角色管理。见图2.2.4;

表2.2.1 角色用户对应关系



图 2.2.1 角色层级关系


imgs/rzhd/ueditor/jpg15556462918087276.jpg

图2.2.2 一般继承关系


imgs/rzhd/ueditor/jpg15556463127753561.jpg

图2.2.3 受限继承关系


imgs/rzhd/ueditor/jpg15556463332067088.jpg


图2.2.4 添加角色和人员


imgs/rzhd/ueditor/jpg15556463556688305.jpg


图2.2.5 角色管理

说明:

  1. 本故事中没有对各个角色的用例进行描述,但是通过表2.2.1,大家可以自行脑补。

  2. 一般继承关系和受限继承关系的区别主要在角色间的关系;见图2.2.2中的红色线条;

  3. 上级角色可以继承多个下级角色的权限,上级角色的权限为所有继承角色的权限的叠加;

  4. 角色间的继承关系可能会和现实中的有所差异,现实中不会出现运营角色继承人力角色的权限情况;

  5. 可能会遇到的问题:由于低级角色的权限全部被高级角色继承,就会导致没有自己角色的私有权限;处理方式会在第三篇常见问题汇总进行说明。

3. 角色限制模型:RABC2
故事3:中午吃饭,同事跟我说,由于公司现在组织结构问题,他们组很多人有多个角色,但是由于现在我们只能设置一个角色,所以他们在工作中需要切换多个账号,很不方便。

这种场景下,可以使用角色限制模型。在理论篇中我们讲过,角色限制模型跟基本模型相比,用户和角色为多对多的关系,如果采用责任分离模型,则需要定义角色和角色间的互斥关系,也就是约束规则。

在本故事中,我们采用动态分离的方式处理互斥的角色的赋予,不能同时。除需要定义角色间的互斥关系外,完成整个权限的设置同RBAC1的步骤类似,包括以下2步。

第一步,抽取业务角色,确定角色和用户间关系;

在本故事中,为了表明角色间的互斥,引入全能型员工用户9,角色为行政主管、人力主管和运营主管。

采用故事2中的方法对角色进行抽取,并确定角色间的互斥关系,见表2.3.1;

第二步,进行原型草图设计;

包括增加角色、增加人员和角色管理,以及多角色用户登录时,对角色的处理。见图2.3.1、图2.3.2、图2.3.3;

表2.3.1 角色间关系



图2.3.1 增加角色和人员


imgs/rzhd/ueditor/jpg15556464765487325.jpg


图2.3.2 角色管理


imgs/rzhd/ueditor/jpg15556464908121000.jpg


图2.3.3 用户选择操作角色

说明:

  1. 当采用静态分离时,互斥的角色不能同时被赋予同一个用户;

  2. 动态分离时,则用户登录后需要选择使用的角色,同时要支持根据需要切换角色;

4. 统一模型:RABC3

统一模型是包括了继承和分离两种情况的更为复杂的模型,即既要定义角色间的的继承关系,也要维护好角色间的责任分离关系。

在这里就不做过多的赘述,因为只要维护好了角色间的约束关系,其他规则类的处理方式同RABC1和RABC2。

由于此模型相对来讲较为复杂,对于一般的系统,前三种就可以满足需求,不建议也没必要使用此种模型。

总结:实战采用了三个故事,对基于角色的权限控制进行了描述,包括RBAC0、RBAC1、RBAC2,由于RBAC3为1和2的集合,并且在实际工作中,使用场景比较少,所以没有进行详细说明。万变不离其宗,只要掌握了基于角色的权限控制的基础理论,根据产品的需求进行设计即可,也不必强制性的生搬硬套模型,下面会对一些常见的问题进行汇总,包括角色数据权限的处理等。


五、常见的问题汇总
问题1:用户、角色和权限的关系,以及如何处理多角色时的权限?

角色和权限为多对多的关系是毋庸置疑的。对于用户和角色的关系,在实战篇中,不同的对应关系并不一样,但是设计时用户、角色最好设计为多对多的关系。

当用户和角色为多对多的关系时,我们就需要考虑多个角色时,权限如何处理,根据业务需求,需要定义角色和角色、权限和权限之间的关系,定义好关系后,根据约束规则进行处理。

问题2:在RBAC1模型中,由于高一级的角色继承了低一级角色的所有权限,会导致低一级的角色没有自己的私有权限。

在有继承关系的角色权限模型中,如果高一级的角色继承了低一级的所有权限,就会导致低一级的角色没有自己的私有权限,这一点和实际的业务会存在不符合的情况。针对这一点的解决办法有:

1)引入私有角色,这种办法会导致角色数量变多,提升了角色管理的复杂性;

2)引入私有权限和公有权限,私有权限不允许继承,公有权限允许继承。不同的业务中对公有和私有的定义会有所不同,如传播深度N;公有、私有和特征,权限是否可被继承,根据继承方式确定,继承方式包括一般继承、公有化继承、私有化继承和无特征继承等。

问题3:角色数据权限如何控制?

作为ToB或者平台类产品,除了功能权限,最为头疼的就是数据权限。实际业务中,相同的角色在同一功能下的数据权限是不同的,比如同为代理商角色,代理商A作为华南区的代理商,在客户管理时,只能查看华南区的;同理代理商B作为华中区的代理商,在客户管理处,则只能查看华中的。

针对这种情况,需要对数据权限进行控制。针对数据权限的控制,可以在设置角色权限时进行控制,如果没有对数据权限进行控制,则默认为所有的数据。

除了数据和功能权限,我们还会遇到字段权限,比如:代理商C和D都能看到华南区的客户情况,但是C看不到客户联系方式,D则能看到联系方式。如果有需要对字段权限进行控制,则可以在设置角色的数据权限或者功能权限时,进行控制。

问题4:权限设计时,在交互层面需要考虑的因素都有哪些。

讲到交互层,就不得不讲用户体验,权限设计也是如此。在保证一定扩展性的基础上考虑用户体验。

平台类或者内部产品,虽然设计宗旨不同,但是也得让我们的用户用着爽不是。

在做功能权限时,有时候开发会说,你这个设计方案不存在无限扩展的可能性啊,我们后期可能存在重新做的风险啊。

如果这个方案指的是业务层面,那可能是真的存在问题,这个时候需要和研发好好沟通一番。但如果是指交互方案,那这个时候我们是可以坚持自己的,因为交互方案肯定是结合产品现状、后期的规划发展以及用户的使用习惯,在保证用户体验的基础上输出的。

虽然前端对数据的解读方式一定程度上依赖于交互方案,但是讲到健壮性和扩展性,改动起来的难易程度也是另外一个维度的度量方式,不是吗?

问题5:权限设置完成后,相应的菜单和功能的状态如何处理。

这个问题主要是指功能权限设置完成后,对应的菜单和功能的入口状态如何处理。一般有两种处理方式:

第一种:显示,点击时告知用户是否有此权限;

第二种:根据权限设置,没有权限直接不予显示。

问题6:是否有必要设置默认账号和默认权限。

对于ToB类或者平台类的产品,正常来讲都会有一个默认的超级管理员的角色以及角色对应的账号,否则系统内第一个角色谁来添加?

默认权限的设置则根据需要进行设置,如果是不必要进行控制的权限,当然是可以设置为默认权限的。



下一章:社区搭建的骨架:4种内容组织形式-APP开发 软件开发 APP开发公司 软件开发公司
软件开发
关于锐智互动

锐智互动网络科技遵循严格的质量和安全标准, 实施严密的安全措施, 拥有成熟可靠的管理和开发流程, 公司凭借多年的行业积累、深厚的 行业专长和成熟的行业实践,为客户持续创造关键价值。我们始终关 注前沿技术,保持国际领先的眼界和技术储备。公司自 成立以来, 在团队成员的共同努力下,已经成功服务于上百家企业,其中包括 我爱我家、联东集团、优财CMA、5100、奔驰、华为、伊利、宝马、 迪思公关、航天国旅、HOTWIND、北京电通等众多知名企业。

咨询热线:400-1050-360

推荐阅读

有什么值得推荐的app开发公司? Tag: app开发公司 如何评估APP软件定制的价格合理性? Tag: APP软件定制 定制化APP软件开发服务,提升企业竞争力 Tag: 定制化APP 软件开发外包的选择标准和方法有哪些? Tag: 软件开发外包 App定制开发的商业模式有哪些?如何评估投资回报? Tag: App定制开发 软件开发定制过程中,如何确保项目质量和进度控制? Tag: 如何确保项目质量和进度控制? 北京程序系统开发:北京的程序系统开发有哪些成功案例? Tag: 北京的程序系统开发有哪些成功案例? 公众号搭建:北京的公众号搭建需要哪些技术支持? Tag: 北京的公众号搭建需要哪些技术支持? 北京程序系统开发:北京的程序系统开发团队规模如何? Tag: 北京的程序系统开发团队规模如何?

提交需求,获取工期与报价

立即咨询