权限系统描述
权限子系统是软件开发中的基础组件,权限的现代软件开发的业务基础,凡开发业务软件必备权限子系统,由此可见权限系统之重要性。
权限系统之所以重要,是权限系统在业务软件中控制用户功能权限权限及数据权限:
1、功能权限:用户可以再页面上做何种操作。
2、数据权限:用户可以再页面上看见何种数据。
权限系统之设计,必须独立于单一的项目,甚至独立于单一平台,使之可在多项目多平台上到达通用之功效。
所以通用权限设计成为各个高手研究的开发技术之一,由此延伸出许多根据应用范围,灵活性的权限设计模型。
权限系统概念
下面先讨论一下权限系统设计中可能设计到的一些概念:
第一、
权限:所谓权限,即页面上拥有的一个功能或者一个操作的定义,拥有该操作该功能用户即拥有该权限。
权限对于入门程序员,有点抽象。我们总是在操作数据库的时候发现自己的账号没有某某权限,解释为该账户没有操作该功能的能力,没有被授予该能力,所以称之为“无此权限”。
操作定义:对一个系统中的所涉及的操作进行定义,比如:浏览,查询,删除,添加...
然而,定义的操作并不是权限,因为这些操作并没有涉及到被操作的对象,也就是说操作只是一个定义,是抽象的,并没有具体到某个对象上的操作。
菜单定义:对系统所涉及的操作对象进行定义,比如:文章管理,水费管理...
然而,定义的菜单并没有包含任何操作,因为并没有涉及到菜单所拥有的操作,也就说菜单只是一个定义,其不存在任何操作。
菜单上的操作:权限。在菜单上的操作称之为权限。权限必然涉及到操作及操作涉及的对象,这里操作的对象就是菜单所指向的页面。
权限系统中权限数据本意应该理解为:菜单上涉及的操作。某用户在某菜单上有某个操作意为:该用户拥有该菜单所指向页面的一个具体权限。
第二、
角色:中文中意为,扮演的人物概念。这些人物概念是抽象的,只有当人员进入了该角色,便拥有出该角色的能力,该角色才具体化。
在权限系统中,角色同样可以这么理解,角色作为系统中被创造出来的人物概念,本身属于抽象范畴。
这些角色拥有的能力,无法被表达,因为角色本身的抽象性。
角色的权限:角色本身拥有权力,也就是角色的权限,我们可以理解为:角色为权限之集合。
用户与角色:用户在系统中拥有角色,好比用户在一个环境下扮演的一个人物,那么用户就拥有该人的一且特征,自然包括权力。这样角色就被具体化,使得去权限为可行权限,而不是定义。
第三、
用户组:将一些人进行归类,提取其共同点,使得该类人因其共同点而相互联系,那么这样的一些人的集合称之为用户组。用户组为用户之分组,用户因为某个共同点而同在一组,便于管理。用户组角色:某类人在特定环境下扮演相同人物、拥有相同能力便表示为用户组之角色。那么用户组下之用户便都拥有该角色所有权限。
权限系统模型设计
权限系统根据应用程度,与程序的规模可以对权限系统的设计进行调整,于是延伸出适合于不同程度的权限系统设计理念。
第一、
RBAC模型、RBAC:Role-Based Access Control
RBAC为经典的权限系统设计模型,意为:基于角色的访问控制。
权限的设计以角色为核心,其实形式为:用户->角色 角色->权限,角色为权限的集合,用户通过拥有角色去获得权限。
RBAC模型的授权是通过对角色进行授权以达到对用户的授权。
RBAC解决了对用户多用户直接授权、传授相同的权限的繁琐与不灵活,使重复授权成为过去,以统一的角色授权设置用户权限。
完全RBAC模型在面对大型应用时,如果为给某个用户授权,那么就必须创建一个角色,长此以往,角色越来越多,管理与工作方面的效率马上就下来。
第二、
RBAC结合用户授权模型:
该模型为解决RBAC的授权不灵活性而产生的,用户授权意为:对用户而非角色的直接授权。
用户授权可以让一些临时或者特定的用户权限的授权直接授予特定用户,避免创建大量角色,便于管理。
RBAC的角色授权与用户直接授权相结合,使得授权操作过程可以根据权限的使用访问灵活考虑角色的创建于只授权,
对临时或单一用户所有的权限授权觉有较高可操作性与可读性。
然而,当用户数量增多,且用户授权所呈现出来的繁琐就会变得突出。
第三、
用户组结合RBAC、用户授权模型:
当软件应用规模进入大规模级别时,RBAC结合用户授权模型就会显示出它疲软,因为角色会变得非常多,独立授权也会非常多,授权无法以
用户集授权,效率下降,管理业变得很麻烦。用户组的出现,可以很好的解决该授权模型弊端,将用户分组,向用户组授权以达到向用户授
权的效果。在大规模应用中,用户数量多,将用户分类授权,可以使授权简单,灵活。同时用户组模型结合RBAC及用户授权模型可以更加灵活面对各种授权。
权限系统在数据库中的定义
权限系统用户为基础进行权限访问控制,那么数据库中必定有权限使用的主体:
1、tabPower_user:用户表的信息,可以根据各个应用的具体情况来设置,其中最基本是:id(用户主键,标示,很重要),userCode。
每个用户都有一个账号,这个账号是可变的,但id不变,所以在权限系统中id将作为数据关联的字段。
2、权限系统中涉及到的所有操作的定义:添加,删除...
tabPower_operate:操作定义,基础表,为权限提供各种操作的名称,该表本身不是权限。其中最基本:id,operateName
3、权限系统菜单表,菜单表的设计差异不多,其中主要是看菜单的级数:一级,二级,还是三级。大型应用中的菜单多为三级。tabPower_menu:id,rootMenu,parentMenu,menu,url。
4、权限系统权限表:
tabPower_OperatePower:权限表为权限系统设计中最为重要的表,它的数据代表着权限系统中的基础的、根本的权限。但说白了,这张表是操作表与菜单表之间多对多的中间表,意为:一个菜单有多个操作,一个操作可出现在多个菜单中。
tabPower_OperatePower:id,menuId,operateId(menuId关联菜单表,operateId关联操作表,意为:菜单上的操作表示权限)
(权限系统中该表为关键表,他代表的实质的权限)
5、权限系统角色表:
tabPower_role:角色表伴随RBAC模型的出现而出现,tabPower_role代表着系统中所有角色的定义,但不包含权限。该表仅仅是个定义。
tabPower_role:id,roleName,系统中所有的角色名称都将出现在这个表中,
6、权限系统角色权限表:
tabPower_rolePower:角色权限表是权限系统中另外一张十分关键的表,它定义了角色的权限,将角色与权限表关联在一起。
我们习惯说:角色是权限的集合,没错,在权限表与角色表之间存在的这张角色权限表代表了多对多的关系,也表达了角色是权限的集合这样一个观点。
7、权限系统用户角色表:
tabPower_roleUser:RBAC模型中的角色用户授权的中间表,关联了用户与角色表之间的关系。一个用户可以拥有多个角色,这是多角色权限系统中根本代表。
tabPower_roleUser:id,userId,roleId
8、权限系统用户权限表:
tabPower_userPower:在用户直接授权模型中,用户权限表定义了用户与权限之间的直接关系,他们是多对多的关系。(又一张关键表)
tabPower_userPower:id,userId,powerId
9、权限系统用户分组表:
tabPower_userGroup:用户分组模型中用户分组的定义,
tabPower_userGroup:id,groupName这张表的结构可以非常简单,呵呵。
10、权限系统用户分组映射表:
tabPower_userToGroup:将用户归入用户分组的数据记录表,该表定义用户分组的结果。
tabPower_userToGroup:id,userId,groupId.
11、权限系统用户组角色表:
tabPower_GroupRole:用户组角色表,在用户分组模型中,该表为中间转化表,将角色与用户分组直接关联,绕过用户表,可以直接为大量人员直接授角色。本表为解决大规模授权不灵活的关键表。
tabPower_GroupRole:id,role,groupId.其结构同样简单,与用户角色表一致。
12、权限系统用户组权限表:
tabPower_groupPower:这张表为解决系统独立授权中出现的情况,该表并不非常重要,作为一个功能扩展加入,可以一定程度提高授权灵活度。
tabPower_groupPower:id,groupId,powerId.
权限系统整体设计图:
权限设计细节
1、权限系统的开发旨在控制用户的权限,其中有个特殊的权限叫做“浏览”,浏览本身并没事对页面进行任何操作,但是作为一种权限,它可以控制用户对菜单项的visible,那么当我们进入业务系统的时候,呈现的菜单栏本质上市一棵菜单树,是用户的账号对应可浏览的菜单集合在页面的上的表示。所以最终要的一个算法就是查询出用户有权限浏览的菜单数据集合,这中间需要做多部分授权的SQL、来union。
2、全系统对于菜单的查询,权限的查询,都需要关联12张,然后通过四部分授权的:角色授权,直接授权,分组角色授权,分组直接授权来合并查询数据,所以这部分的表字段尽量减少,仅留下必要的数据以提高查询的效率,避免权限系统设计的数据量到系统运行出现低效率。
3、角色设计部分,角色可以分类:常规角色,临时角色。
常规角色:权限永久有效的角色,无时间上的限制。
临时角色:权限在指定的时间段上有效,在此之外则无效。