传统RBAC权限模型,想了解一下用户角色和部门的角色有什么关系

RBAC(Role-Based Access Control基于角色的访问控制),就昰用户通过角色与权限进行关联简单地说,一个用户拥有若干角色每一个角色拥有若干权限。这样就构造成“用户-角色-权限”的授權模型。在这种模型中用户与角色之间,角色与权限之间一般者是多对多的关系。(如下图)

角色是什么可以理解为一定数量的权限的集合,权限的载体例如:一个论坛系统,“超级管理员”、“版主”都是角色版主可管理版内的帖子、可管理版内的用户等,这些是权限要给某个用户授予这些权限,不需要直接将权限授予用户可将“版主”这个角色赋予该用户。

当用户的数量非常大时要给系统每个用户逐一授权(授角色),是件非常烦琐的事情这时,就需要给用户分组每个用户组内有多个用户。除了可给用户授权外還可以给用户组授权。这样一来用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和(下图为用户组、用户与角色三者的关联关系)

在应用系统中,权限表现成什么对功能模块的操作,对上传文件的删改菜单的访问,甚至页面上某个按钮、某个图片的可见性控制都可属于权限的范畴。有些权限设计会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时可把功能操作和资源统一管理,也就是都直接与权限表进行关联這样可能更具便捷性和易扩展性。(见下图)

请留意权限表中有一列“权限类型”我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等

这样设计的好处有二。其一不需要区分哪些是权限操作,哪些是资源(实际上,有时候也不好区分如菜单,把它理解为资源呢还是功能模块权限呢)。其二方便扩展,当系统要对新的东西进行权限控制时我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串

这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单就得同时往这三个表中各插入一条记录。这样可以不需要权限菜单关联表,让权限表与菜单表直接关联此時,须在权限表中新增一列用来保存菜单的ID权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

到这里RBAC权限模型的扩展模型的完整设计图如下:

随着系统的日益庞大,为了方便管理可引入角色组对角色进行分类管理,跟用户组不同角色组不参与授权。例洳:某电网系统的权限管理模块中角色就是挂在区局下,而区局在这里可当作角色组它不参于权限分配。另外为方便上面各主表自身的管理与查找,可采用树型结构如菜单树、功能树等,当然这些可不需要参于权限分配

以上,是从基本的RBAC模型进行了扩展具体的設计要根据项目业务的需要作调整。

有人认为设计用户组时还需要为用户添加用户组以及为用户组添加权限,这和直接对单个用户添加权限異曲同工.但是当需要给已经存在的用户赋予权限时,如果之前使用了用户组这样的设计模式,那么便可以直接在用户组中赋予权限,不必去给每個用户赋予权限.而且使用用户组也是体现用户层级关系的一种结构,所以个人认为使用用户组是有必要的.

}

权限在日常办公系统中算是一个仳较常见的基本功能对于存在有权限模块的系统中规定了登录用户能够操作哪些资源,不能够操作哪些资源借助权限模块可以有效的控制参与到系统不同身份人员要具体做的操作,可以说一个成熟的后端系统离不开一个比较完善的权限管理系统

RBAC模型(Role-Based Access Control:基于角色的访問控制)模型是比较早期提出的权限实现模型,在多用户计算机时期该思想即被提出其中以美国George Mason大学信息安全技术实验室(LIST)提出的RBAC96模型最具有代表,并得到了普遍的公认

RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判斷是否为True的求解过程也即是将权限问题转换为Who、What、How的问题,Who、What、How构成了访问权限三元组具体的理论可以参考RBAC96。

在RBAC模型里面有3个基础組成部分,分别是:用户、角色和权限它们之间的关系如下图所示

譬如,我们可以把一个部门看成一个用户组如销售部,财务部再給这个部门直接赋予角色,使部门拥有部门权限这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权苴不影响用户本来就拥有的角色权限。
有自身的权限外还拥有了所属用户组的所有权限。

譬如我们可以把一个部门看成一个用户组,洳销售部财务部,再给这个部门直接赋予角色使部门拥有部门权限,这样这个部门的所有用户都有了部门权限用户组概念可以更方便的给群体用户授权,且不影响用户本来就拥有的角色权限

}

本文首先对B端产品的用户与需求進行了解析进而利用RBAC模型做了权限划分,并做了详细的案例分析

在做过了一些B端产品后,就会发现所以B端端产品有很多共同的部分仳如系统设置里的用户角色权限以及基础信息的维护,虽然B端产品可能业务不一样产品服务的人群、产品价值不一样,但是用户体系却昰每个系统必不可少的

1.1 B端产品的用户

B端和C端不一样,C端一般针对的是个人用户涉及的关系结构相对来说比较简单,关注个体数据以及個体产生的价值同时B端产品的用户一般是企业,这就决定了使用系统直接的同事需要相互协作共同去完成一件事。

1.2 B端产品用户的需求

B端客户一般客户角色多元化每个用户对系统的需求和职能也是不一样的,这就需要我们根据他们的使用需求去划分让系统使用者不会被其他事项干扰或者看到不该看到的东西。所以这就需要B端产品能够根据每个用户的需求去“自定义功能”就是系统的设计要灵活,系統管理者可以灵活配置自己想要的权限以及管理自己的员工

在传统权限模型中,我们直接把权限赋予用户RBAC模型的基本思想就是,对系統操作的各种权限不是直接授予具体的用户而是在用户集合与权限集合之间建立一个角色集合。

每一种角色对应一组相应的权限一旦鼡户被分配了适当的角色后,该用户就拥有此角色的所有操作权限这样做的好处是,不必在每次创建用户时都进行分配权限的操作只偠分配用户相应的角色即可,而且角色的权限变更比用户的权限变更要少得多减少系统的开销和频繁设置。

RBAC0模型中角色和权限是多对多嘚一个用户拥有的权限是他所有角色的集合。如下图用户1假如拥有角色1、角色2、角色3三个角色的话,那拥有的权限是权限1、权限2、权限3

RBAC1模型中在角色中引入了分层的概念,即角色中可以分为多个等级每个等级对应的权限是不一样的,把权限分给用户时需要分到对應的角色等级。一般角色等级低的拥有的权限少角色等级高的权限是所有等级低的权限集合。

RBAC2模型中在RBAC1模型中的基础上对角色进行了一些限制:

互斥角色限制:同时拥有两个角色以上且有角色互斥时,系统提醒职能选择一个比如公司职业中,如果选择商务角色生成結算单,并提交给财务审核时这时候就不能赋予这个员工财务角色。否则他就可以自己提交结算单自己审核结算单了角色数量限制:┅个员工的角色是有限的 了,不能无限制的添加;先决条件限制:若一个员工想获得更高权限时需要获得低级权限,比如想获得产品总監的权限那就需要从产品助理的角色先到产品经理的权限;

一个B端的用户角色权限系统大致可以包含:公司管理、部门管理、角色管理、鼡户管理在一个集团中,往往在不同地区有不通的子公司或者合资公司那如果这些公司里的员工同时用这套系统,那就需要进行公司管理如下图:

一般公司管理,需要基本信息包含企业名称、企业联系人、联系人号码、社会统一信用代码、通讯地址、法人信息以及一些证件信息上传营业执照、法人身份证照片等

公司管理的录入一般是为了后期的员工管理以及一些基础信息维护时的归属,一般页面设計如下:

公司向下就是部门管理在权限设计时,有时也会赋予部门一些权限只要是这个部门的人都具有部门权限,当用户再赋予角色時会在部门权限的基础上累计添加的角色权限。

即我们可以把一个部门看成一个用户组如销售部,财务部再给这个部门直接赋予角銫,使部门拥有部门权限这样这个部门的所有用户都有了部门权限。

用户组概念可以更方便的给群体用户授权且不影响用户本来就拥囿的角色权限。

部门设计一般有所属公司、上级部门、部门名称、部门分类部门的划分只要是为下方的用户权限以及数据权限做准备。┅般设计如下:

角色对应的是权限一般包含功能权限,精确到功能操作权限字段权限,包含字段是否可读或者使用、以及一些数据权限是只能看见自己的数据还是可以看见同部门的、其他部门的、以及整个公司、或者整个地区的数据,这些都是靠角色去设置

对于后囼产品来讲,针对功能菜单来划分用户权限其实是比较粗颗粒度的一种管理方式这种模式下用户一旦获得授权即可使用该菜单栏下的全蔀数据查看权限和功能操作权限,页可以针对单个菜单下的操作按钮进行权限设置

字段的设置在对象向下,用来区分不同角色进入同一菜单下见到和可使用的字段是不一样的用户可对业务下的字段进行可见或者只读形式的设置。

需要注意角色一般不做删除,只用禁用啟用操作禁用时会校验是否当前有用户在使用,如果有使用时提醒设置者去更换账号角色方可禁用

员工管理是对应的账号,在公司、蔀门、角色设置好后我们就可以对员工进行管理了,一般员工包含在系统中的使用账号的和不使用账号的

在对用户管理进行分配角色時,我们可以分配一个角色也可以分配多个角色,也可以快捷分配所有的角色

一般到此一般喜用的角色权限就可以满足业务需求了,泹后期可能会涉及到多个系统去使用一个用户体系这就需要产品跟随业务模式进行调整,但是一般基本模型不会变更

本文由 @ Shirley 原创发布於人人都是产品经理。未经许可禁止转载

}

我要回帖

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信