基于组织角色的权限设计

很久没有写博客了, 最近研究了一下权限方面的资料,和你们分享一下基于组织角色的权限设计思路。web

 1、 目标:windows

  1. 能够对功能进行权限控制,控制粒度能够达到页面级别和控件级别
  2. 能够对数据进行权限控制
  3. 能够按角色、按人、按部门、按岗位等受权,
  4. 能够分级受权,方便管理   

2、 设计思路 架构

 

1. 模块spa

模块是一个抽象的概念,大到能够表示一个系统,小到能够表示一个控件的功能,包括了菜单、模块、页面、功能、数据权限及数据权限表达式等。设计

1)   菜单:是一个指向某个功能的指针,指向一个页面或者功能,因此能够将其视为一个功能。3d

2)   模块:页面功能的分类,模块下面拥在子模块和页面。指针

3)   页面:呈现给最终用户的界面,用户经过页面来和系统交互,根据系统的不一样,BS架构时是web页面, CS架构时是windows界面。blog

4)   控件功能:每一个界面上的控件,例如保存、删除等按钮所表明的功能,某个控件的显示功能等继承

5)   数据权限: 标识一个须要进行权限控制的数据集合,下面包含多个权限表达式,每个表达式就是一个SQL语句的where条件的一部分。例如查看所有的表达式是 1= 1, 查看本部门的数据的表达式是 DepartmentId = ‘$User.DepartId$’、查看个人数据的表达式是UserId = ‘$User.UserId$’。ci

6)   权限表达式:用来对数据进行过滤,本质上是一个SQL语句的where条件的一部分。每一个表达式都拥有优先级,当同时拥有多个表达式时,取优先级高的表达式。

 

     2. 角色

角色是一组功能的集合,一个角色包含了多个功能权限,方便管理员进行受权,例如系统管理员拥有后台管理的功能,后台管理的功能包括相关菜单的权限、相关界面及控件的操做权限。

 

  3. 组织

组织分为公司、部门、岗位和人员4级,其中公司和部门能够自循环,公司下面能够有子公司, 部门下面能够有子部门。

受权时,将角色分配给组织上的节点,能够将角色分配给公司、部门、岗位和人员,下级节点自动继承上级组织的权限, 给某个部门分配角色后, 该部门下面的子部门和相关人员就都具备了该角色所拥有的权限。当某我的归属到组织上后,就自动拥有组织的权限。在分配权限时,采用权限递增的原则进行分配。

 

4. 分级受权

分级受权时,只能分配那些分配给组织的权限,这个和组织所拥有的权限是不一样的, 例如某个组织节点拥有10项权限, 可是能够分配的权限可能只是这10个中的一部分。

 

 5. 相关问题

1)   用户和组织中的人员是什么关系?

人员是用户与组织的关系的表示, 若是一我的只有一个岗位,那么在组织中就会有一我的员。若是用户在组织中有多个岗位,即一人多岗的状况,那么在组织中就会有多我的员。

 

2)   受权时,为何不直接把模块分配给组织,而要先把模块分配给角色,再把角色分配给组织?

由于模块中的功能粒度过细,用户的管理员分不清楚每个模块具体有什么功能,但用户知道角色表明的意义。例如用户的管理员知道会计角色,可是不知道会计具体使用哪些功能。

这样角色和组织中的岗位会有必定的重叠,可是二者又有一些区别。组织中的岗位是用户在实际生活中的角色, 而系统中的角色是为了方便权限管理而设置的,即权限角色。实际生活中的角色可能拥有多个权限角色。例如总经理可能拥有所有的权限角色,而在组织中总经理是一个岗位。 

 

3、库表设计

  相关表以CM_开头( Common的简写)

序号

表名

说明

1

CM_User

用户

2

CM_Org

组织

3

CM_OrgRole

组织角色

4

CM_Role

角色

5

CM_RoleModule

角色功能

6

CM_Module

功能

7

CM_OrgManModule

组织管理的功能(分级受权用)

  库表关系图:

 

 

 

4、后续思考

  一、系统应该基于角色的权限控制。

  二、角色有层级关系,其做用主要用于角色管理,而不是权限继承。

  三、组织表明了角色,当组织存在的时候,可让程序自动为每一个组织中的节点创建一个角色,以免组织与角色的重叠。

  四、人员与组织是多对多关系,应该要创建一个组织人员表,而不是将人员也归到组织表中去。

  五、为了方便受权,应该有如下几个功能:按功能受权,按角色受权(包括按人受权)

  六、有组织的按组织受权,没有组织的按角色受权

相关文章
相关标签/搜索