当前位置: Coin163 >>

系统权限管理设计及实现思路

2013-09-16 | 所属分类:权限设计 实现
 

l   需求: oa 系统包含众多模块,要求能够通过权限管理,控制不同用户对模块的访问权限,而且需要控制到(增删改查) CRUD 操作的级别。要求能通过角色对用户进行统一授权,在某些特殊情况下,能够单独对用户进行授权。

l   分析

n   概念模型

用户角色  

l   设计:

n   在用户与角色的关系中,以用户为主来进行设计符合客户的使用习惯,即“将多个角色授予某个用户(让用户拥有多个角色)”,比“将多个用户添加到某个角色上”更加让人容易理解。

n   模块的授权以针对角色为主,即大部分的情况下,针对角色来分配模块的权限

n   一旦根据角色划分好权限之后,就可以进行用户的创建工作,同时可以给用户分配角色(可以为多个),用户将拥有其所属角色的所有权限(这样就达到了统一控制的目的)

n   由于一个用户可以拥有多个角色,系统无法对角色的授权进行控制(或者说无需对其授权进行控制,因为为了给客户提供更大的灵活性),所以很有可能出现授权有冲突的多个角色被授予同一个用户的情况,比如:角色 A 对模块 A 有删除权限,但角色 B 对模块 A 的删除权限则被禁止,这时候,如果将角色 A 和角色 B 同时授予用户 A ,则会造成困扰,究竟用户 A 对模块 A 的删除权限是允许还是不允许?它应该是以角色 A 的授权为准,还是应该以角色 B 的授权为准?针对这个问题,可以考虑如下解决办法:

u   第一种解决办法是:如果多个角色之间有授权冲突,则不允许将这些角色同时授予同一个用户,比如,在上述例子中,不允许将角色 A 和角色 B 同时授予用户 A

u   第二种解决办法是:允许将有授权冲突的角色同时授予同一个用户,但用户在某个时刻只能扮演其中的某个角色。在用户登陆后台管理界面之后,可以通过切换角色,来执行不同的操作!

u   第三种解决办法是:允许将有授权冲突的角色同时授予同一个用户,对用户的这些角色来说,有优先级的概念,当将角色分配给用户的时候,应该设置它的优先级。同一个角色在不同的用户那里可能具有不同的优先级。当授权有冲突的时候,以优先级更高的角色授权为准。

u   第一种解决办法限制太死,不够灵活;第二种解决办法,客户的反馈是不够方便(需要不断切换);因此本设计方案将采取第三种解决办法

n   至此,用户与角色之间的设计思路便清晰起来:

 

       用户角色2

n   再来看授权,可以把模块的增删改查操作授予某个角色或用户,并设置为允许或禁止此操作。我们可以考虑使用授权控制列表来存储授权信息。现有需求下,授权的主要要素是:一个是角色或用户;一个是模块;一个是操作;一个是允许 / 禁止。这也就是授权控制列表( ACL )的主要要素。

n   进一步的思考是:操作包括“增删改查”四种操作,针对这每一种操作,需要一个对应的“允许 / 禁止”标识。最直观和直接的考虑便是: ACL 针对每种操作设置一个属性,和一个“允许 / 禁止”的标识。但是这种设计会造成灵活性的缺失。比如有可能随着需求的变更,添加了其它的操作类型,那时候必须对 ACL 做必要的更改才能适应需求的变化。为了适应这种可预见的需求,可将操作及其“允许 / 禁止”标识设计如下:

u   ACL 中,设计一个 int 类型的状态位: aclState ,在 Java 中, int 类型有 32 位,用位 (bit) 来表示操作类型(暂定:第 0 位表示“增”;第 1 位表示“删”;第 2 位表示“改”;第 3 位表示“查”),位的值(对于“位”来说,只能取值 0 1 )用来表示“允许 / 禁止”( 0 表示禁止, 1 表示允许)。这样,操作类型及其“允许 / 禁止”标识便能合二为一,而且提高了灵活性(能支持将来可能会增加的多达 32 种操作类型),因为对于某个模块而言,针对这个模块的操作能够超过 32 个的情况,是几乎不会发生的,因此对这种特殊情况可以不予考虑。

     权限acl

 

n   客户要求在特殊的情况下,能够直接对用户进行授权。意思是不管其角色的授权如何,始终采取针对用户的授权来作为最终的授权。而且,要求控制到的粒度是模块(即可以针对某个模块设置给某用户单独的授权)。当然,在设置好授权之后,可以在适当的时候再开放给用户使用。因此,这里有一个针对用户的授权是否有效的问题。可采取添加另外一个 int 类型的状态位( aclTriState )的办法来满足这种需求。这个额外状态位用 -1 表示针对用户的授权无效;用 0 表示针对用户的授权有效。之所以使用 -1 0 来表示无效 / 有效,是因为 -1 代表了一个 32 位全 1 int 类型值;而 0 则代表了一个 32 位全 0 int 类型值。此设计隐含的意思是: aclTriState 的位与 aclState 的位一致,而且某个位所表示的操作也是一致的,取 1 表示无效,取 0 表示有效(用 0 还是 1 来表示有效,这是无关紧要的事情)。这种设计是为了将来可能扩展的需要。现在的需求是能对 模块 的授权控制其有效 / 无效即可,将来有可能需要对 模块的操作 (增删改查)的授权控制其有效 / 无效。这种控制粒度更细。如果要控制到更细的粒度,那么, aclTriState 可以取更多的状态值,来表示操作级别的有效 / 无效。

u   有效 / 无效的意思是:如果无效,则用户对此模块的授权将受到其所属角色的统一控制;如果有效,则角色对此模块的授权将无法影响到拥有这个角色的用户的授权。

 

   权限acl

l   实现

n   权限管理模块在实现上,有多个用例需要实现:管理模块信息、管理用户信息、管理角色信息、给用户分配角色、给角色授权、给用户授权、获取用户授权列表、判断用户对某个模块的某操作是否有允许授权

n   其中比较重要的是:授权、获取用户授权列表以及判断用户对某个模块的某操作是否有允许授权

u   授权:可针对用户或角色授权,在授权界面上,根据系统现有模块,列出授权树,可选择其中的某些模块和某些操作进行授权。因为鉴于授权界面的复杂性, 采取 DWR 来辅助实现授权界面。

u   获取用户授权列表:在用户登陆系统之后,需要根据用户的授权情况,获得用户的授权列表,并根据用户的授权列表,在后台界面的导航菜单上显示出用户拥有权限的模块,允许用户对这些模块进行操作。

u   判断用户对某个模块的某操作是否有允许授权:为了控制用户对模块的增删改查操作,需要根据用户的授权情况,决定是否显示“增加”、“删除”、“修改”等按钮或链接。我们采取自定义 JSTL 函数的方式来控制界面的显示!如:

 

<!-- login.id表示当前登陆用户,’person’表示模块标识,3代表删除操作 -->

<c:if test="${my:hasPermission(login.id,'person',3) }">

       <a href="#" onclick="del('person.do?method=del&id=${person.id }');">删除</a>

</c:if>

 

 

 

上一篇:
下一篇:

关于Coin163网站地图

Copyright 2012-2013 Coin163.com ( Coin163 ) All Rights Reserved