实现业务系统中的用户权限管理
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字段相关联,因为:
二 人员映射表如下图:
我们来了解一下人员映射表与管理组表以及人员表之间的字段关联,如下图:
看图中的红圈部分,先看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表记录着所有管理员的信息,每添加一个管理员,该表就会增加一条记录。
分享到:
相关推荐
RBAC 权限控制 设计文档 演示文稿 基于RBAC的权限控制系统设计演示文稿 以学校教学系统为实例
Java语言基于RBAC模型设计的权限模型,麻雀虽小,五脏俱全,SpringBoot项目加mysql实例表数据,可以启动运行。 1:参考脚本建mysql数据库 2:导入脚本 3:用idea加载项目 启动项目
Gin Web由gin + gorm + jwt + casbin组合实现的RBAC权限管理脚手架Golang版, 搭建完成即可快速、高效投入业务开发特性RESTful API 设计规范Gin 一款高效的golang web框架MySQL 数据库存储Jwt 用户认证, 登入登出一键...
在大型信息系统的设计中,访问控制一直是一项复杂的工作。...RBACCCS中用了参数化权限,在权限检查时用上下文变量实例化这些参数化权限,这样就解决了上下文的表示和上下文作用机制问题。最后对RBACCCS模型进行
1.基于rbac的权限管理 RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权...
Blog.Core 开箱即用的企业级前后端分离【 .NET Core6.0 Api + Vue 2.x + RBAC】权限框架。ASP.NET Core 5.0 教程,,前后端分离的后端接口,vue教程的姊妹篇。 商业授权付费版( 包含开源版 框架模块/组件模块 中的...
为了解决现有基于角色的访问控制(RBAC)模型缺乏对上下文约束条件的动态调整和生成,无法根据调整后的感知条件对用户权限实时进行调节的问题,在融合上下文感知RBAC模型和基于推理的RBAC模型基础上,提出了基于推理的上...
基于RBAC模型及Windows动态链接库的思想,提出一种模块式的应用程序框架。该框架根据用户信息从权限表、角色权限表、用户表中查询在用户权限范围内可操作的功能模块的相关信息,并由此动态加载实现该功能模块的动态...
基于RBAC的权限访问控制设计 RBAC是指基于角色的访问控制,本篇主要描述了ThinkPHP的RBAC设计思想和使用实例,给出了一个统一和方便的权限控制解决方案
针对传统基于角色的访问控制(RBAC)的局限性,提出了一种基于...最后通过结合某信息管理系统开发实例,讨论了OC-RBAC在信息管理系统中的设计和应用。通过实验证明,0C-RBAC模型与传统RBAC相比有较高的效率和适应能力。
本文实例讲述了thinkPHP框架RBAC实现原理。分享给大家供大家参考,具体如下: RBAC就是:Role Based Access Controller,基于角色(role)的权限(Access)管理,这里简单介绍一下他的原理与实现方式之一。 Part 1 ...
ThinkPHP之RBAC权限把控 ThinkPHP后端框架 ThinkPHP数组改造 ThinkPHP结合BootStrap极速开发动漫项目 PHP企业网站运营 PHP软件开发全集 Smarty模板引擎 BootStrap前端框架 CSS样式设计 HTML5标签和CSS3样式 HTML页面...
5.RBAC-完成添加角色和权限的功能-1 5.RBAC-完成添加角色和权限的功能-2 6.选择权限时JS的智能选择 7.角色完成 第四天 1.管理员管理 2.RBAC-权限的验证-完成 3.商品模块需求分析 4.商品模块表结构设计 5.类型管理 第...
用户菜单权限来自数据库,简单起见,user用户表中同事配置了用户菜单权限,感兴趣的小伙伴可以自行使用RBAC方案扩展数据库表设计进行完善。 运行环境 jdk8+tomcat9+mysql+IntelliJ IDEA+maven 项目技术(必填) ...
用户应用系统的具体操作者,我这里设计用户是可以直接给用户分配菜单/按钮,也可以通过角色分配权限。 角色为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,以上所有的权限资源都可以分配给角色,...
设计思路源于经典的RBAC模型,即:用户通过角色操作资源。在实现上,基本实现了功能权限,包含了资源菜单的显示控制以及页面上按钮粒度的显示控制。并且附送了使用Springboot发送邮件的功能。数据库:链接:...
根据变电站自动化系统对访问控制的需求,分析了IED设备信息模型和信息交换服务这两种访问控制的操作对象,通过对其粒度的粗细划分及访问策略研究,基于RBAC方法设计一种多粒度的访问控制系统。该系统在逻辑上是集中...
结合计算机支持的协同设计(CSOD)系统的具体特点,对角色委托授权...与传统的RBAc角色授权模式不同,该模型将权限的集中方式管理分散实施,使权限管理更加灵活方便。最后通过CSCD系统实例对上述RDA模型进行了验证。
完善的 RBAC 权限控制,用户信息通过网关解析到请求头,随后通过自定义注解 @RequireRole @RequirePermission,可以灵活有效的进行 API 级别的权限控制。分支版本Branch 1.5.12:基于 Spring Boot 1.5.12.RELEASE ...
该模型具有对用户授予和屏蔽权限、数据权限和服务实例权限等特征,能够很好地满足微服务架构下的资源访问控制需求。讨论访问控制模型的实现,对比集中式鉴权与独立式鉴权两种实现的优缺点,说明不同实现方式所适用的...