精华内容
下载资源
问答
  • 权限管理系统设计

    千次阅读 2012-08-16 09:57:23
    通用数据权限管理系统设计(一) 前言: 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能...
    通用数据权限管理系统设计(一)
    前言:
    本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。
    解释:
    功能权限:能做什么的问题,如增加销售订单;
    数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单;
    术语:
    资源:系统中的资源,主要是各种业务对象,如销售单、付款单等;
    操作类型:对资源可能的访问方法,如增加、删除、修改等;
    功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等;
    数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等;
    数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;
    权限:角色可使用的功能,分角色的功能权限和角色的数据权限;
    角色:特定权限的集合;
    用户:参与系统活动的主体,如人,系统等。
    通用数据权限管理系统设计(二)
    方法说明:
    在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。
    本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。
    本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。
    这段话比较绕口,下面举个例子实际例子。
    某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:
        销售总监        -- 能察看所有销售部的销售订单;
        北京销售经理 -- 只能察看北京销售部的所有销售订单;
        上海销售经理 -- 只能察看上海销售部的所有销售订单;   
        广州销售经理 -- 只能察看广州销售部的所有销售订单;   
    上述角色的定义如下:
           -------------------------------------------------------------------
         角色名称             功能             数据类型     数据对象   
           -------------------------------------------------------------------
         销售总监           察看销售订单                                  
         北京销售经理       察看销售订单         部门         北京   
         上海销售经理       察看销售订单         部门         上海      
         广州销售经理       察看销售订单         部门         广州      
           -------------------------------------------------------------------
        上述定义中,销售总监只定义了功能权限,而没有定义数据权限,所以销售总监能够察看所有的销售订单;而其他几位销售经理分别定义了这一功能的数据权限,所以只能察看指定部门的销售订单。
         在实际应用中,往往会出现部门分组,组长能够察看本组所有人员处理的销售订单的情况,以及某些情况下,某些人只能察看本人的销售订单的情况,这些特殊情况在上述的说明中无法解决,需要在设计和实现中进行处理。
        北京销售代表 -- 只能察看北京销售部的本人的所有销售订单;   
         北京销售代表         察看销售订单           部门            北京      
                                                     个人                   
    通用数据权限管理系统设计(三)--数据库设计
    我们先来看看传统的基于角色的权限管理系统,如下图所示,最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。
          图一:基于角色的数据库结构
    为实现数据权限控制,在设计上对基于角色的权限管理进行扩充,如下图所示:
    图二:通用数据权限管理系统数据库设计
    对比两张图,我们可以看到,他们之间的主要变化为:
    1、 增加系统资源信息和操作类型信息,系统资源为树形结构、如销售模块、销售订单等;操作类型记录可能的操作,如增加、删除、修改、查看、查询等,系统功能是资源与操作类型的组合,对资源的操作就是系统功能。
    2、 增加数据对象类型和数据对象两张表,数据对象类型记录系统中需要控制的对象类型,如部门、库房、员工、客户、供应商等;数据对象记录各对象类型的对象实例,如北京销售部、上海销售部、张三、李四等等。(独立保存的好处后面会说到)
    3、 增加系统资源与数据对象类型的关联表(多对多),本表为配置表,说明某种资源可能需要的控制点,如销售订单与部门类型的关联可能涉及到分部门分配权限;销售订单与客户的关联可能涉及到按客户分配权限等等。
    4、 增加数据对象与角色权限的关联,这张表是真正最终实现数据权限管理的所在地。
    通过这种设计,能够最小化地减少对原有权限系统的更改,并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用,能够灵活满足客户的需要。

    展开全文
  • 本文笔者会将理论知识与自己的实践经验相结合,分享权限管理系统设计的相关知识,希望能给读者带来启发。一、权限管理系统概述1、权限管理系统的作用对整个后台系统进行权限控制,目的是为了避免系统的使用者因为...

    599fbedbc5c800429a5c2a52ef807bbc.png

    对于后台系统来说,权限管理是必不可少的一个环节。本文笔者会将理论知识与自己的实践经验相结合,分享权限管理系统设计的相关知识,希望能给读者带来启发。

    一、权限管理系统概述

    1、权限管理系统的作用

    对整个后台系统进行权限控制,目的是为了避免系统的使用者因为权限控制的缺失而出现操作不当、数据泄露、流程卡住等问题。

    2、权限管理系统的三要素

    这里说的三要素是系统中的三大功能模块,分别是账号、角色和权限。权限管理系统的存在,概括的讲是为了将三要素间的关系安排清楚。

    2c96f6dacc99eb6fb5634fd40003cfe7.png

    (1)账号

    每个后台系统的使用者,都有自己的账号。账号是使用者进入系统这扇大门的钥匙,它的权限对应着使用者在系统中的操作范围。后台产品的账号,通常是由公司内部人员进行创建。

    (2)角色

    角色是搭建在账号与权限之间的一道桥梁。系统中会有很多权限,如果每建一个账号都要配置一遍权限,将是很繁琐的一项工作。因此,角色作为使用者人群的集合,把需要的权限收归于其中,然后再根据账号的需要来配置角色。通常会根据不同的部门、职位、工作内容等,对角色进行设置。

    角色这一概念的引入,极大地增加了权限管理系统配置的灵活性和便捷性。创建账号时,可以将不同的角色配置在同一个账号上,也可以给不同的账号配置相同的角色。创建角色时,可以根据角色的差异赋予其不同的权限。

    (3)权限

    权限可分为三类:数据权限、操作权限和页面权限。

    数据权限:控制账号可看到的数据范围。举例说明,风控系统中,负责不同区域的信审人员,只能看到自己负责区域的标的,不能看到和修改其他区域的。

    页面权限:控制账号可以看到的页面,通常系统都会有这一层权限控制。这种控制相对操作权限来说比较粗放,难以对权限进行精细管理。

    操作权限:控制账号在页面上可以操作的按钮,通常指的是页面中的新增、删除、编辑、查询功能。没有操作权限,就只能看到页面中的数据,但是不能对数据进行操作。操作权限是比页面权限更精细一层的权限控制。

    3、RBAC模型

    (1)定义

    RBAC(Role-Based Access Control)意思是基于角色的权限控制,有别于传统模型中的直接把权限赋予账号,增加了“角色”的概念,把权限赋予角色,再将角色赋予账号。提高了账号管理效率,降低了出错的概率。

    例如:当有多个账号需要配置相同的权限时,有了角色后便不需要给每个账号挨个配置权限,只需要在角色上配置权限,再把角色配置到账号上。如果想批量调整账号的权限,只需要调整账号对应的角色的权限,无需对每个账号进行调整。

    (2)类型

    RBAC模型根据设计需要,可分为RBAC0、RBAC1、RBAC2、RBAC3四种类型。其中RBAC0是基础,另外三种是RBAC0的升级。产品经理在进行权限系统设计时,可以结合实际情况来选择使用的RBAC模型的类型。

    二、权限管理系统设计实例

    下文以笔者曾负责过的系统为例,来讲述如何进行权限管理系统设计。此系统类型为RBAC0,即把权限赋予角色,角色赋予账号,账号、角色、权限之间是多对多的关系。为防止暴露公司系统真实情况,已进行删减。

    0bceea484d728be58dcc5787f27d1390.png

    1、账号管理

    (1)页面展示

    账号管理模块是对系统用户的信息进行管理,在列表中要展示重要性较高的字段,便于识别账号。例如:编号、真实姓名、用户名、部门、角色、创建时间、账号状态等(页面如下图)。

    需要能通过“真实姓名”和“用户名”来查询账号,便于管理员定位到想要操作的账号。除此之外,还需要有“新建账号”功能。

    80b2cef12719e90b5da59b3af47ebb10.png

    (2)新建账号

    新建账号功能可跳转页面或弹窗展示(如下图),页面信息除账号基本信息外,还需要对账号赋予角色。

    719f31c69e8531535f1d690b870120d5.png

    (3)编辑账号

    除了需要创建新账号外,还需要对已有的账号进行修改(操作栏中“编辑”功能),账号用户的真实姓名和用户名不可修改,其他信息可修改。

    9217f527b6bf7da74950dc7364a8ed9b.png

    2、角色管理

    (1)页面展示

    角色,即为拥有共同特征的同一类人群身份的归纳,所以在角色管理页面中,需要设置能够识别角色特征的字段。例如:角色名称、角色描述、创建时间、更新时间、状态等(如下图页面)。

    角色数量通常不会太多,数量较少时可取消查询功能,但“新建角色”功能是必不可少的。

    04c37bd9fa096324cfe70f72af345b28.png

    (2)新建角色

    新建角色即是对角色进行描述并赋予权限的过程,若权限数量不多,可采用下拉列表的方式选择。若权限数量多且分类繁杂,则可采用分组列表的方式展示,让用户通过复选框勾选。为了操作简便,建议增加全选/反选功能。

    4ae7063470dd9a26d79c0ea488985ca4.png

    (3)编辑角色

    操作栏中的“编辑”功能,对已有角色进行修改,角色的名称、描述、状态、权限均可修改,每次修改后在列表中记录更新时间。

    93615b21976a4ccd6ded6535d4997fcb.png

    (4)对应账号

    指的是配置过该角色的账号,点击后在新页面中打开,展示账号信息,包括账号的真实姓名、用户名、部门、创建时间、账号状态,并可在列表中对账号进行编辑。

    12885aeb12a4e76e760edc3e8898d53b.png

    3、权限管理

    (1)页面设计

    若系统中权限数量较多且权限类型复杂(页面权限、操作权限、数据权限),为了保证管理员使用便捷及减低出错概率,可以将权限管理页面以列表的形式展示,展示页面包含权限编号、名称、类型、描述、创建时间等。

    若系统权限较为简单,则可用树状图来展示权限,不需要对权限做过多描述。

    (2)新增权限

    新增权限的输入页面,不同的系统要求不同,有的需要开发录入代码,有的需要产品经理录入新权限的URL,还有的系统中不展示新增权限入口。产品经理在设计时需要和开发沟通,选择适合目前技术能力的方案。

    三、RBAC0模型的三种扩展

    338a5db5e934edc1798291c5650972ea.png

    1、RBAC1模型(角色分级模型)

    该模型在RBAC0模型的基础上,引入了角色间的继承关系。将角色划分层级,每个层级拥有的权限不同,每个层级的下级角色只能按照系统的设置,继承上级角色的部分权限。以此来对角色的关系进行精细化管理。

    例如:在风控体系中,风控经理、风控主管、风控专员可分为三个不同层级。风控主管拥有风控经理的部分权限,而风控专员拥有风控主管的部分权限。

    2、RBAC2模型(角色限制模型)

    该模型也是以RBAC0模型为基础,引入了角色间的限制条件,共有4种限制条件。

    (1)角色互斥

    在系统的互斥角色集合中存在相互制约的角色,这些角色不能分配给同一个账号。例如:风控系统中的尽调角色和审核角色即为互斥角色,不能配置在同一个账号上。

    (2)基数限制

    某个角色被分配给账号的数量有限制,不允许超过数量限制的账号拥有该角色。例如:专门为公司某个职位的高管建立的角色(CEO)。

    (3)先决条件限制

    即账号想要获得高层级的角色,则需要先拥有低层级的角色。例如:先拥有风控主管的权限,才能拥有风控经理的权限。

    (4)运行限制

    允许一个账号拥有两个角色的权限,但是运行时只能激活其中一个。

    3、RBAC3(统一模型)

    同时包含RBAC1和RBAC2的特性,既有角色层级划分,也有各种限制,在此不再赘述。

    四、补充说明

    1、用户组设置

    一般来说权限管理系统不需要设置用户组,只要当用户基数较大,角色类型过多时,为了便于管理员进行操作,才会引入“用户组”的概念。

    用户组可以理解为,将某个部门的所有人看成一个用户组,再给用户组赋予角色,这个部门的所有人就都有了用户组中角色的权限。对于给群体账号赋予权限,用户组可以提供很大的便利。

    同时,用户组中的账号,除拥有用户组的权限外,还可以拥有指定的角色。

    2、角色的数据权限控制

    在实际业务中,相同的角色在同一页面中,所拥有的数据权限可能不同。例如:负责不同区域的审核人员能看到各自负责区域的数据。所以在设置角色的权限时,需要结合实际业务情况对角色的数据权限进行设置。也可能会出现同样的角色,在同一个页面上,能够查看到的字段权限不一样。

    3、未设置权限的展示

    对于角色中未设置的权限,在页面上有两种展示方式。第一种比较常见,根据权限的设置来展示,没有权限的不予展示。第二种是显示所有的功能和权限,点击时告知用户是否有此权限。

    五、小结

    以上是笔者对于权限管理系统设计的心得,文中所举的设计实例较为简单,目的是让未接触过此类系统的读者能对其有所了解。至于了解之后如何对自己负责的系统进行设计,就需要各位读者结合自己所在公司的需要进行设计了。

    喜欢的话请点赞和收藏 (●'◡'●)ノ

    公众号:打酱油的白熊,欢迎关注公众号交流。

    展开全文
  • 通用角色权限管理系统设计

    千次下载 热门讨论 2012-05-01 17:25:48
    通用角色权限管理系统设计 因为做过的一些系统的权限管理的功能虽然在逐步完善,但总有些不尽人意的地方,总想抽个时间来更好的思考一下权限系统的设计。 权限系统一直以来是我们应用系统不可缺少的一个部分,若每...
  • 企业级权限管理系统设计,支持菜单权限、按钮权限、数据权限、权限可以设置无限极,非常实用,满足90%以上的企业应用
  • 通用权限管理系统设计篇 通用权限管理系统设计
  • 通用数据权限管理系统设计

    千次阅读 2018-03-08 15:33:38
    通用数据权限管理系统设计(一) 作者:逸云 前言: 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即...
    通用数据权限管理系统设计(一)
     
    作者:逸云
     
    前言:
     本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。
     
    解释:
     功能权限:能做什么的问题,如增加销售订单;
     数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单;
     
    术语:
     资源:系统中的资源,主要是各种业务对象,如销售单、付款单等;
     操作类型:对资源可能的访问方法,如增加、删除、修改等;
     功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等;
     数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等;
     数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;
     权限:角色可使用的功能,分角色的功能权限和角色的数据权限;
     角色:特定权限的集合;
     用户:参与系统活动的主体,如人,系统等。
     
     
    通用数据权限管理系统设计(二)
     
    方法说明:
     在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。
     
     本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。
    本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。
     
     这段话比较绕口,下面举个例子实际例子。
     
     某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:
        销售总监      -- 能察看所有销售部的销售订单;
        北京销售经理 -- 只能察看北京销售部的所有销售订单;
        上海销售经理 -- 只能察看上海销售部的所有销售订单;  
        广州销售经理 -- 只能察看广州销售部的所有销售订单;  
     
     上述角色的定义如下:
     
         -------------------------------------------------------------------
         角色名称             功能             数据类型     数据对象  
         -------------------------------------------------------------------
         销售总监           察看销售订单                                 
         北京销售经理       察看销售订单         部门         北京  
         上海销售经理       察看销售订单         部门         上海     
         广州销售经理       察看销售订单         部门         广州     
         -------------------------------------------------------------------
     
        上述定义中,销售总监只定义了功能权限,而没有定义数据权限,所以销售总监能够察看所有的销售订单;而其他几位销售经理分别定义了这一功能的数据权限,所以只能察看指定部门的销售订单。
     
         在实际应用中,往往会出现部门分组,组长能够察看本组所有人员处理的销售订单的情况,以及某些情况下,某些人只能察看本人的销售订单的情况,这些特殊情况在上述的说明中无法解决,需要在设计和实现中进行处理。
     
     
        北京销售代表 -- 只能察看北京销售部的本人的所有销售订单;  
         北京销售代表         察看销售订单           部门            北京     
                                                     个人                  
     
     
    通用数据权限管理系统设计(三)--数据库设计
     
    我们先来看看传统的基于角色的权限管理系统,如下图所示,最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。
        图一:基于角色的数据库结构
    为实现数据权限控制,在设计上对基于角色的权限管理进行扩充,如下图所示:
     
    图二:通用数据权限管理系统数据库设计
    对比两张图,我们可以看到,他们之间的主要变化为:
    1、 增加系统资源信息和操作类型信息,系统资源为树形结构、如销售模块、销售订单等;操作类型记录可能的操作,如增加、删除、修改、查看、查询等,系统功能是资源与操作类型的组合,对资源的操作就是系统功能。
    2、 增加数据对象类型和数据对象两张表,数据对象类型记录系统中需要控制的对象类型,如部门、库房、员工、客户、供应商等;数据对象记录各对象类型的对象实例,如北京销售部、上海销售部、张三、李四等等。(独立保存的好处后面会说到)
    3、 增加系统资源与数据对象类型的关联表(多对多),本表为配置表,说明某种资源可能需要的控制点,如销售订单与部门类型的关联可能涉及到分部门分配权限;销售订单与客户的关联可能涉及到按客户分配权限等等。
    4、 增加数据对象与角色权限的关联,这张表是真正最终实现数据权限管理的所在地。
     
    通过这种设计,能够最小化地减少对原有权限系统的更改,并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用,能够灵活满足客户的需要。
     
    下一篇文章将讨论这种结构如何满足第二部分功能需求的问题,如果时间允许,将对程序的设计做进一步阐述。
     
    本设计方法已应用于自行开发的通用供应链管理系统中,欢迎指正。
    展开全文
  • 一个权限管理系统设计案例

    千次阅读 2019-11-25 13:51:12
    一个权限管理系统设计案例

    扫码关注,点击【薇茑精选】查看:
    《一个经典的权限管理数据库表设计案例》

    关注公众号「程猿薇茑」 阅读技术文章
    **微信扫一扫**
    展开全文
  • 权限管理系统设计 什么是RBAC RBAC(Role- Based Access Control) 用户=>角色=>权限 基于角色的访问控制 权限管理 哪些页面要设置权限 哪些操作要设置权限 哪些数据要设置权限 基于RBAC的数据表设计 用户表...
  • 后台权限管理系统设计(图文教程) 2019.5.27转载于肖朋伟| https://blog.csdn.net/qq_40147863/article/details/85320371 这里给大家分享一个网站后台管理系统的所有功能介绍,操作演示...
  • 权限,系统管理,权限设计,权限数据库详细设计,很详细的权限管理设计
  • 若在阅读本片文章遇到权限操作问题,请查看本系列的前两章!...现在步入正题,这篇文章是关于自有权限管理系统设计的思路描述,自有权限管理系统是抛弃django自带的后台管理界面,基于自己编写的权限管理界面对用户权...
  • 今天和大家一起探讨权限管理方面的设计心得。权限管理,是B端后台系统一个重要的组成部分,属于底层的支撑功能,系统内所有的功能,甚至字段的增减都涉及到权限的分配和管理。因此怎样配置后台的权限系统,以适应...
  • 1.2 要素分析2 数据权限设计2.1 规则元2.2 规则元配置2.3 数据规则的配置2.4 数据规则的解析2.5 确定当前查询适用的数据规则 1 数据权限概述 1.1 什么是数据权限? 数据权限是指对系统用户进行数据资源可见性的控制...
  • 权限系统一直以来是应用系统中不可缺少的一个部分,若每个应用系统都重新对系统权限进行设计,以满足不同系统用户的需求,将会浪费我们不少宝贵时间,所以花实践设计一个相对通用的权限管理系统是非常有意义的。...
  • Django权限管理系统设计分析

    千次阅读 2019-07-14 17:40:58
    权限管理顾名思义,其实就是角色控制权限的系统,每个用户对应一个角色,每个角色有对应的权限,比如公司会有CEO,总监,销售经理,销售员,每个人的权限都不一样,那我们给他展示的url也都不同 一、首先创建项目,...
  • 该文档为通用权限设计方案,其中通过分析用户、组、角色、权限等四个对象之间的关系具体描述权限设计的大致思路。
  • 10129_权限管理系统 技术:SSM 工具 eclipse + tomact + mysql + jdk 功能详情: 后台首页 管理员管理 系统管理 系统公告

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,969
精华内容 4,387
关键字:

权限管理系统设计