星星号

栏目分类:
返回
快速导航关闭
当前搜索
当前分类
热门搜索
星星号 > 编程知识 > 正文

(权限设计七张表)权限设计表结构超详细

作者:用户投稿 发布时间:2023-02-07 16:12:14 阅读次数:

本篇文章给大家谈谈权限设计七张表,以及权限设计表结构超详细对应的知识点,文章可能有点长,但是希望大家可以阅读完,增长自己的知识,最重要的是希望对各位有所帮助,可以解决了您的问题,不要忘了收藏本站喔。

本文目录一览:

shiro权限控制有哪几张数据表

shiro权限控制有哪几张数据表

根据Shiro的设计思路,用户与角色之前的关系为多对多,角色与权限之间的关系也是多对多。在数据库中需要因此建立5张表,分别是用户表(存储用户名,密码,盐等)、角色表(角色名称,相关描述等)、权限表(权限名称,相关描述等)、用户-角色对应中间表(以用户ID和角色ID作为联合主键)、角色-权限对应中间表(以角色ID和权限ID作为联合主键)。具体dao与service的实现本文不提供。

用户权限设计

基于角色的访问控制模型就是把“用户—角色—操作—资源”关联到一起,实现非自主型访问控制策略。使用基于角色的访问控制模型可以减轻安全管理工作,因为某种任务是稳定的,而负责该项任务的人员是经常变化的,这种方式只需把新的用户分配给已有的角色即可,无需为用户重新指定资源和操作,因而简化了授权管理工作。

为了保障本系统操作使用的信息安全,系统登录认证体系由三个要素组成:用户、角色、权限,三者相辅相成,共同组成系统的安全运行屏障。

1.用户信息

用户信息表统一管理,在用户信息表中存储用户名称、登录名、口令、各子系统权限、用户角色信息等。

用户信息表的添加、删除以及子系统权限修改由总系统授权的管理员执行,本系统中,用户信息表的操作在业务处理与信息服务子系统的系统管理菜单下的用户信息管理页面。用户口令可以自行改变,用户权限的变更需要提请管理员同意,并由管理员修改。

子系统启动时读取用户信息表验证用户权限,在系统运行时依据权限分配相应的功能。依据用户在子系统中的权限级别控制用户可操作的功能,实现最终用户对ORACLE数据库中数据的读取和添加操作权限控制(表8-2)。

表8-2 用户信息结构表

2.角色信息

角色可以根据需要任意多地添加,多个角色权限组合生成多个权限控制,对应到一个确定的用户,赋予用户对功能模块的控制权限。用户角色表包括角色名称、用户唯一值编码等信息。示例见表8-3。

表8-3 用户角色表(示例)

在数据库中为各个功能模块建立了功能名称表,每个功能模块均有记录,有功能编码和功能名称及其他附属信息。功能名称示例见表8-4。

表8-4 功能名称表(示例)

每个用户必须属于至少一个角色,每个角色具备多个功能的控制权限,功能权限通过角色传递给用户,从而实现用户对功能的操作权限控制。

3.权限信息

权限表明了用户可执行的操作。系统权限控制采用最大优先,用户可以拥有多个角色,每个角色对每一页面都可拥有权限,但在权限结果判断时只以最大权限为主,即管理员级权限大于并包含访问者权限。功能权限示例如表8-5所示。

表8-5 功能权限表(示例)

系统规划的子系统权限等级见表8-6。

表8-6 子系统权限等级规划表(部分)

续表

4.用户认证授权

通过四个表将用户、角色与权限组合起来,可以形成无穷多的用户权限组合,直接控制用户权限到每个细分功能。

用户、角色、权限、功能控制流程如图8-1所示:

图8-1 用户权限控制流程图

功能权限表仅在部署角色权限时使用,标示功能具备的可部署权限。

在角色中必须保证有一个管理角色拥有用户管理功能的管理权限,防止不能分配角色与权限,同样在用户中必须保证至少有一个用户是管理角色。

软件设计后台操作用户权限管理的方案

B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。

需求陈述

不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。

可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。

权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。

满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。

关于设计

借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。

我们先来分析一下数据库结构:

首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:

这三个表之间的关系是多对多的,一个权限可能同时属于多个管理组,一个管理组中也可能同时包含多个权限。同样的道理,一个人员可能同时属于多个管理组,而一个管理组中也可能同时包含多个人员。如下图:

由于这三张表之间存在着多对多的关系,那么它们之间的交互,最好使用另外两张表来完成。而这两张表起着映射的作用,分别是“actiongroup”表(以下简称“权限映射表”)和“mastergroup”表(以下简称“人员映射表”),前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图:

另外,还需要一张表来控制系统运行时左侧菜单中的权限分栏,也就是“权限分栏表”,如下图:

根据上面的分析,我们进行数据库结构设计,如下图:

点击这里查看权限管理系统数据表字段设计

为了能够进行良好的分析,我们将数据库结构图拆分开来,三张实体表的作用已经很清晰,现在我们来看一下两张映射表的作用。

一 权限映射表 如下图:

首先,我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。

看图中的红圈,先看gorupid字段相关联,这种关联方式在实际数据库中的表现如下图:

如图中所示,管理组表中“超级管理员”的groupid为1,那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。

使用groupid字段关联,是为了查到一个管理组能够执行的权限有哪些。但这些权限的详细信息却是action字段关联所查询到的。

action字段相关联在数据库中的表现如下图:

通过这种关联,才查询到权限映射表之中那些权限的详细信息。综合起来,我们就知道了一个管理组可以执行的权限有哪些,以及这些权限的详细信息是什么。

或许你会问,为什么不使用actionid字段相关联呢?因为:

权限表中的id字段在经过多次的数据库操作之后可能会发生更改。

权限映射表中仅仅记录着一个管理组可以执行的权限。

一旦权限表中的id更改,那么权限映射表中的记录也就更改了。

一个管理组可以执行的权限势必将出错,这是非常不希望的。

考虑到上面的情况,所以应该使用action字段相关联,因为:

在权限表中,id可能发生变化,而action字段却是在任何情况下也不可能发生变化的。

权限映射表中记录的action字段也就不会变。

一个管理组可以执行的权限就不会出错了。

二 人员映射表 如下图:

我们来了解一下人员映射表与管理组表以及人员表之间的字段关联,如下图:

看图中的红圈部分,先看groupid字段关联,这种关联方式在数据库中的表现如下图:

如图,“超级管理员”组的groupid为1,我们再看人员映射表,admin属于超级管理员组,而administrator属于超级管理员组,同时也属于管理员组。

使用这种关联方式,是为了查到一个管理组中的人员有谁。和上面一样,人员的详细信息是靠id字段(人员映射表中是masterid字段)关联查询到的。

id字段(人员映射表中是masterid字段)关联表现在数据库中的形式如下图:

一个人员可能同时属于多个“管理组”,如图中,administrator就同时属于两个“管理组”。所以,在人员映射表中关于administrator的记录就会是两条。

这种关联方式才查询到管理组中人员的详细信息有哪些。综合起来,才可以知道一个管理组中的人员有谁,以及这个人员的详细信息。

再结合上面谈到的权限表和权限映射表,就实现了需求中的“组”操作,如下图:

其实,管理组表中仅仅记录着组的基本信息,如名称,组id等等。至于一个组中人员的详细信息,以及该组能够执行的权限的详细信息,都记录在人员表和权限表中。两张映射表才真正记录着一个组有哪些人员,能够执行哪些权限。通过两张映射表的衔接,三张实体表之间的交互才得以实现,从而完成了需求中提到的“组”操作。

我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下图:

两张表使用了actioncolumnid字段相关联,这种关联方式在数据库中的表现如下图:

如图所示,通过这种关联方式,我们可以非常清晰的看到权限表中的权限属于哪个分栏。

现在,数据库结构已经很清晰了,分配权限的功能以及“组”操作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。

为什么使用这种数据库设计方式搭建起来的系统可以重用呢?

三张实体表中记录着系统中的三个决定性元素。“权限”,“组”和“人”。而这三种元素可以任意添加,彼此之间不受影响。无论是那种类型的业务系统,这三个决定性元素是不会变的,也就意味着结构上不会变,而变的仅仅是数据。

两张映射表中记录着三个元素之间的关系。但这些关系完全是人为创建的,需要变化的时候,只是对数据库中的记录进行操作,无需改动结构。

权限分栏表中记录着系统使用时显示的分栏。无论是要添加分栏,修改分栏还是减少分栏,也只不过是操作记录而已。

综上所述,这样设计数据库,系统是完全可以重用的,并且经受得住“变更”考验的。

总结:

此套系统的重点在于,三张实体表牢牢地抓住了系统的核心成分,而两张映射表完美地映射出三张实体表之间的交互。其难点在于,理解映射表的工作,它记录着关系,并且实现了“组”操作的概念。而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。

附录:

权限管理系统数据表的字段设计

下面我们来看看权限管理系统的数据库表设计,共分为六张表,如下图:

action表:

action表中记录着系统中所有的动作,以及动作相关描述。

actioncolumn表:

actioncolumn表中记录着动作的分栏,系统运行时,左侧菜单栏提供了几块不同的功能,每一块就是一个分栏,每添加一个分栏,该表中的记录就会增加一条,相对应的,左侧菜单栏中也会新增机一个栏。

actiongroup表:

actiongroup表记录着动作所在的组。

groupmanager表:

groupmanager表记录着管理组的相关信息,每添加一个管理组,这里的记录就会增加一条。

mastergroup表:

mastergroup表记录着管理员所在的管理组,由于一名管理员可能同同时属于多个组,所以该表中关于某一名管理员的记录可能有多条。

master表:

master表记录着所有管理员的信息,每添加一个管理员,该表就会增加一条记录。

怎么设计用户权限管理系统数据库?要用到哪几张表?每张表有哪些字段?

1、首先在oracle数据库创建教学管理系统需,要用到的数据表如下。

2、上述中数据表的其他信息创建。(departments表、class表、students表、course表)。

3、步骤一中数据表的其他信息创建。(teacher表、teach表、score表)。

4、然后对创建的数据表按要求输入数据值。

5、最后按照上述要求继续用插入语句添加数据值。

6、查询学生信息表中学生的学号、姓名、性别、出生日期、班级编码,并以汉字标题显示字段名。就完成了。

用户表,权限表,角色表,怎么设计。

1、先建一个用户表users,字段大概就是id,password。

2、再建立一个user_roles用户角色表,user_roles.userid 与 users.id关联。

3、建立一个”用户权限表“sys_permissions,大概字段id、permission,description

4、建一个"用户角色权限表"sys_role_permissions,两个字段roleid、permissionid

5、user_roles.id=sys_role_permissions.roleid 和

sys_permissions.id = sys_role_permissions.permissionid

从零开始码后台管理系统——权限表设计

前后台可以正式接通以后,我们就可以设计基础的几个数据库表了,菜单表、角色表、用户表、角色菜单表和用户角色表,有这5个表我们就可以搞定用户权限。

因为要开始涉及数据库操作,每个表的单表操作我们都会创建Controller、Service、Entity、Mapper、MapperXML,我们先来新建数据库表结构,先建立最基础的表结构,后续有需要再完善,毕竟使用了MybatisPlus,改变结构之后只需要在实体类加属性就好了。

用户表:

角色表:

用户角色表:

菜单表:

角色菜单表:

在用户表中插入超管账号:

引入Lombok方便写实体类

新建用户相关类:

修改完善部分登录服务代码:

重启项目调用登录,控制台输出一下内容

LoginForm(username=admin, password=21232f297a57a5a743894a0e4a801fc3)

SysUserEntity(id=1, username=admin, password=admin, salt=123456, name=超级管理员, createTime=2022-01-27T17:14:16, createBy=null, updateTime=2022-01-27T17:14:16, updateBy=null)

SaLog -->: 账号[admin]登录成功

整体登录流程就是这样了,继续完善。先确定密码加密方式:

md5(md5(password)+md5(salt))

在测试类中生成密码存到数据库中

登录接口中密码已经在前端经过md5加密,所以修改后端代码

新建菜单Controller

重启登录

OK,接下来从完善菜单管理开始逐步写。

如何设计用户、角色、权限表

权限设计你可以用一个编号

ADMIN

0表示超级管理员

1表示会员

2表示游客等

然后增加一个权限表

0是管理员的权限内容

1是会员的权限内容

不就OK了

一、申请自己的网站空间和域名;

二、制作自己的网站;[可以用Dreamwever2008、PS配合,也可以在硅谷动力看视频教程];

三、把自己做好的站上传上去;

四、网站的后期维护与管理;

五、可以联系我Q275423182

B端产品之权限设计(RBAC权限模型)

一、前言

随着互联网的快速发展,B端行业也逐渐崛起,很多企业管理中使用的软件我们通常称其为B端管理系统,而在B端系统中“权限管理”是必不可少的功能,不同的系统中权限的应用复杂程度不一样,都是根据实际产品以及需求情况而设置合理的权限。而我们现在对于权限的设置基本上都是建立在RBAC权限模型上的、扩展的,下面我会通过介绍RBAC权限模型的概念以及结合实际业务情况列举权限设置的应用。

二、什么是RBAC权限模型?

RBAC是Role-BasedAccess Control的英文缩写,意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What进行How的操作,也就是“主体”对“客体”的操作。其中who是权限的拥有者或主体(例如:User、Role),what是资源或对象(Resource、Class)。

简单的理解其理念就是将“角色”这个概念赋予用户,在系统中用户与权限之间通过角色进行关联,以这样的方法来实现灵活配置。

RBAC其实是一种分析模型,主要分为:基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。

RBAC权限模型是基于角色的权限控制。模型中有几个关键的术语:

用户:系统接口及访问的操作者

权限:能够访问某接口或者做某操作的授权资格

角色:具有一类相同操作权限的用户的总称

1)RBAC0

RBAC0是RBAC权限模型的核心思想,RBAC1、RBAC2、RBAC3都是在RBAC0上进行扩展的。RBAC0是由四部分构成:用户、角色、会话、许可。用户和角色的含义很简单,通过字面意思即可明白,会话:指用户被赋予角色的过程,称之为会话或者是说激活角色;许可: 就是角色拥有的权限(操作和和被控制的对象),简单的说就是用户可使用的功能或者可查看的数据。

用户与角色是多对多的关系,用户与会话是一对一的关系,会话与角色是一对多的关系,角色与许可是多对多的关系。

2)RBAC1

RBAC1是在RBAC0权限模型的基础上,在角色中加入了继承的概念,添加了继承发的概念后,角色就有了上下级或者等级关系。

举例:集团权责清单下包含的角色有:系统管理员、总部权责管理员、区域权责管理员、普通用户,当管理方式向下兼容时,就可以采用RBAC1的继承关系来实现权限的设置。上层角色拥有下层的所有角色的权限,且上层角色可拥有额外的权限

3)RBAC2

RBAC2是在RBAC0权限模型的基础上,在用户和角色以及会话和角色之间分别加入了约束的概念(职责分离),职责分离指的是同一个人不能拥有两种特定的权限(例如财务部的纳入和支出,或者运动员和裁判员等等)。

用户和角色的约束有以下几种形式:

互斥角色:同一个用户在两个互斥角色中只能选择一个(也会存在一个用户拥有多个角色情况,但是需要通过切换用户角色来实现对不同业务操作)

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

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

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

例如:iconfont和蓝湖的用户与角色就采用了约束的概念,超级管理员只允许只有一个

4)RBAC3

RBAC3是RBAC1与RBAC2的合集,所以RBAC3包含继承和约束。

二、为什么要引用RBAC权限模型?

RBAC中具有角色的概念,如果没有角色这个概念,那么在系统中,每个用户都需要单独设置权限,而系统中所涉及到的功能权限和数据权限都非常多,每个用户都单独设置权限对于维护权限的管理员来说无疑是一件繁琐且工作量巨大的任务。

而引入角色这个概念后,我们只需要给系统设置不同的角色, 给角色赋予权限,再将用户与角色关联,这样用户所关联的角色就直接拥有了该角色下的所有权限。

例如:用户1~用户8分别拥有以下权限,,不同用户具有相同权限的我用不同的颜色做了区分,如下图:

在没有引入RBAC权限模型的情况下,用户与权限的关系图可采用下图的杨叔叔展示,每个用户分别设置对应的权限,即便是具有相同权限的用户也需要多次设置权限。

引入RBAC权限模型及引入了角色的概念,根据上面表格的统计,用户1、用户3、用户5、用户8拥有的权限相同,用户2、用户6、用户7拥有相同的权限,用户4是独立的权限,所以我们这里可以根据数据统计,以及实际的需求情况,可以建立三个不同的角色,角色A、角色B、角色C,三个角色分别对应三组用户不同的权限,如下图所示:

对应的上面的案例表格我们就可以调整为含有角色列的数据表,这样便可以清楚的知道每个用户所对应的角色及权限。

通过引用RBAC权限模型后,对于系统中大量的用户的权限设置可以更好的建立管理,角色的引入让具有相同权限的用户可以统一关联到相同的的角色中,这样只需要在系统中设置一次角色的权限,后续的用户便可以直接关联这些角色,这样就省去了重复设置权限的过程,对于大型平台的应用上,用户的数量成千上万,这样就可避免在设置权限这项工作上浪费大量的时间。

三、引入用户组的概念

我们依旧拿上面表格案例举例,虽然前面我们应用的RBAC权限模型的概念,但是对于大量用户拥有相同权限的用户,我们同样的也需要对每个用户设置对应的角色,如果一个部门上万人,那么我们就需要给这个部门上万人分别设置角色,而这上万其实是具有相同的权限的,如果直接采用基础的RBAC权限模型的话,那么面对这样的情况,无疑也是具有一个庞大的重复的工作量,并且也不利于后期用户变更的维护管理,那么针对相同用户具有相同的权限的情况,我们便可以引入用户组的概念。

什么是用户组呢? 用户组:把具有相同角色的用户进行分类。

上面我们的数据表格案例中的用户1、用户3、用户5、用户8具有相同的角色A,用户2、用户6、用户7也拥有相同的角色B,那么我们就可以将这些具有相同角色的用户建立用户组的关系,拿上面的案例,我们分别对相同角色的用户建立组关系,如下:

用户1、用户3、用户5、用户8→建立用户组1

用户2、用户6、用户7→建立用户组2

因为用户4只有一个用户,所以直接还是单独建立用户与角色的关系,不需要建立用户组,当然尽管只有一个用户也是可以建立用户组的关系,这样有利于后期其他用户与用于4具有相同的角色时,就可以直接将其他用户添加到这个用户组下即可,根据业务的实际情况而选择适合的方案即可。

通过案例表格的变化我们就可以直观的看出权限设置变得清晰简洁了,通过第用户组赋予角色,可以减少大量的重复的工作,我们常见的企业组织、部门下经常会出现不同用户具有相同角色的情况,所以采用用户组的方式,便可以很好的解决这个问题,给具有相同权限的用户建立用户组,将用户组关联到对应的角色下,此用户组就拥有了此角色下的所有权限,而用户是属于用户组的,所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组,一个用户组也可以包括多个用户,所以用户与用户组是多对多的关系。

四、引入权限组的概念

权限组与用户组的原理,是将一些相对固定的功能或者权限建立组的关系,然后再给此权限组赋予角色,目前我所接触的B端项目中使用权限组的概念的比较少,可简单的看一下关系图

四、功能权限和数据权限

B端系统中一般产品的权限由页面、操作和数据构成。页面与操作相互关联,必须拥有页面权限,才能分配该页面下对应的操作权限,数据可被增删改查。所以将权限管理分为 功能权限管理和数据权限管理。

功能权限管理:指的是用户可看到那些模块,能操作那些按钮,因为企业中的用户拥有不同的角色,拥有的职责也是不同的。

数据权限管理:指的是用户可看到哪些模块的哪些数据。

例如:一个系统中包含多个权责清单(清单1、清单2、清单3),系统管理员能对整个系统操作维护。

完整内容请查看公众号原文链接

原文链接:B端产品之权限设计(RBAC权限模型)

来源公众号《设计小余》

怎么设计用户权限管理系统数据库?要用到哪几张表?每张表有哪些字段?

什么样的权限?菜单权限?

一般用户表,角色表,模块表(或者菜单啊反正是你要权限的东西),然后角色和模块的表

这是最简单的结构,用户关联角色,角色关联模块,用角色去控制权限,增删改查什么的模块表呢,就是你要控制的东西,比菜单,根据登录人的角色,看有哪些模块,然后显示这些模块其他的模块隐藏。

如果需要复杂的东西,中间可以加别的东西,具体看你需求了

至于字段,用户和角色就没什么可说的,无法就是名字啊什么的

模块表也简单,比如模块名称,ID,父子模块id(如果有父子模块的话),具体字段还是要看需求。

手把手教你做系统权限设计,看完不要说还不会

权限管理是所有后台系统的都会涉及的一个重要组成部分,主要目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题。

迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制(Role-Based Access Control)

RBAC-0模型是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。

用户 是发起操作的主体,按类型分可分为2B和2C用户,可以是后台管理系统的用户,可以是OA系统的内部员工,也可以是面向C端的用户,比如阿里云的用户。

角色 起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。

有人会问了为什么用户不直接关联权限呢?在用户基数小的系统,比如20个人的小系统,管理员可以直接把用户和权限关联,工作量并不大,选择一个用户勾选下需要的权限就完事了。

但是在实际企业系统中,用户基数比较大,其中很多人的权限都是一样的,就是个普通访问权限,如果管理员给100人甚至更多授权,工作量巨大。

这就引入了 "角色(Role)" 概念,一个角色可以与多个用户关联,管理员只需要把该角色赋予用户,那么用户就有了该角色下的所有权限,这样设计既提升了效率,也有很大的拓展性。

权限 是用户可以访问的资源,包括页面权限,操作权限,数据权限:

是RBAC的核心设计及模型分析,此模型也叫做RBAC-0,而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC-1,RBAC-2,RBAC-3模型。下面介绍这三种类型

此模型引入了角色继承(Hierarchical Role)概念,即角色具有上下级的关系,角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。

而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。这种设计可以给角色分组和分层,一定程度简化了权限管理工作。

基于核心模型的基础上,进行了角色的约束控制,RBAC2模型中添加了责任分离关系。

其规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

责任分离包括静态责任分离和动态责任分离。主要包括以下约束:

即最全面的权限管理,它是基于RBAC-0,将RBAC-1和RBAC-2进行了整合。

当平台用户基数增大,角色类型增多时,而且有一部分人具有相同的属性,比如财务部的所有员工,如果直接给用户分配角色,管理员的工作量就会很大。

如果把相同属性的用户归类到某用户组,那么管理员直接给用户组分配角色,用户组里的每个用户即可拥有该角色,以后其他用户加入用户组后,即可自动获取用户组的所有角色,退出用户组,同时也撤销了用户组下的角色,无须管理员手动管理角色。

根据用户组是否有上下级关系,可以分为有上下级的用户组和普通用户组:

每个公司都会涉及到到组织和职位,下面就重点介绍这两个。

我们可以把组织与角色进行关联,用户加入组织后,就会自动获得该组织的全部角色,无须管理员手动授予,大大减少工作量,同时用户在调岗时,只需调整组织,角色即可批量调整。

组织的另外一个作用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。

每个组织部门下都会有多个职位,比如财务部有总监,会计,出纳等职位,虽然都在同一部门,但是每个职位的权限是不同的,职位高的拥有更多的权限。

总监拥有所有权限,会计和出纳拥有部分权限。特殊情况下,一个人可能身兼多职。

根据场景,新的权限模型就可以设计出来了,如下图:

根据系统的复杂度不同,其中的多对多关系和一对一关系可能会有变化

授权即给用户授予角色,按流程可分为手动授权和审批授权。权限中心可同时配置这两种,可提高授权的灵活性。

有了上述的权限模型,设计表结构就不难了,下面是多系统下的表结构,简单设计下,主要提供思路:

在项目中可以采用其中一种框架,它们的优缺点以及如何使用会在后面的文章中详细介绍。

权限系统可以说是整个系统中最基础,同时也可以很复杂的,在实际项目中,会遇到多个系统,多个用户类型,多个使用场景,这就需要具体问题具体分析,但最核心的RBAC模型是不变的,我们可以在其基础上进行扩展来满足需求。

好了,文章到这里就结束啦,如果本次分享的权限设计七张表和权限设计表结构超详细问题对您有所帮助,还望关注下本站哦!

推荐文章:

  • (excel2010教程)excel2010教程800集
  • (环境变量怎么恢复默认)环境变量怎么恢复默认设置
  • (windows7序列号)windows7序列号生成器
  • (viewstate)viewstate反序列化
  • (模板论坛)个人论坛模板
  • (writeprivateprofilestring)writeprivateprofilestring作用
  • (android手机开发)android手机开发放161作用
  • (为什么卡巴斯基老是更新失败)卡巴斯基数据库更新不了
  • (birthdate)birthdates
  • (全局钩子)全局钩子实现进程保护
  • Tag: 权限设计七张表
    欢迎分享转载→ (权限设计七张表)权限设计表结构超详细
    本文地址:https://www.nvaweb.com/biancheng/4824.html

    编程知识栏目本月最新文章

    本站最新文章

    我们一直用心在做

    Copyright © 2021-2022 星星号-(www.nvaweb.com) 版权所有