乐在其中

以JEE为主攻,以Flex为点缀,以Eclipse RCP为乐趣
请访问http://www.inframesh.org

首页 新随笔 联系 管理
  43 Posts :: 0 Stories :: 8 Comments :: 0 Trackbacks

1 权限控制体系中的基本概念

  1.1 身份与主题

  身份(Principal)描述的是用户以及和用户相关的社会关系的属性,例如角色、群组、职位等等。

  主题(Subject)是身份的集合,描述的是一个用户所具有的所有身份。

  下图表示用户的身份:

  图1 用户身份关系图

  1.2 资源与资源域

  资源是系统中的一种存在,包括具体资源和抽象资源。

  具体资源,是实实在在的资源,例如系统模块、页面中的按钮、等等。

  抽象资源,可以说是一种描述性资源,例如表达式资源等。

  资源域(Resource Domain)是系统中资源的类别,是对多样性资源的一种划分方式。

  一个资源域可以包含多种类型的资源,资源的类型在.net中可以用代表该资源的类来表示,同一种类型的资源是以资源的标识来加以区分的。

  一个资源在系统中的是以“资源域-资源类型-资源标识”来唯一标识和定位的。

  资源域的一个例子:

  图2 资源域实例图

  1.3 操作

  操作(Action),描述的是对某种资源可能的行为,对于某种资源往往可能有多种操作,例如对于文档资源,可能的操作为查看(view)、编辑(edit)、删除(delete)、移动(move)等。

  如果对于某种资源的操作较多,可能会出现某些操作之间有包含关系,而某些操作之间没有包含关系的情况。例如上面对于文档的几种操作中,一般拉来说,编辑应该包含查看,而删除应该包含编辑等等,而编辑和移动之间就不一定有包含关系。

  对于操作之间的包含关系,可以通过下面的树形结构来说明:

  图3 资源操作图

1.4 许可与权限

  许可(Permission)描述的是对系统中资源的操作,“通常一个许可包含一个目标(‘由这个权限控制的操作将对谁执行?’)和一个操作(‘如果这个权限允许的话,对这个目标将执行什么操作?’)”。

  许可=资源 + 操作。

  权限,可以认为是对许可的一种更为常用的说法,在实际的程序设计中,权限往往被附加上了身份的描述。

  权限=[身份+]资源+ 操作。

  1.5 允许权限与拒绝权限

  Ø 允许权限,明确允许身份A能够对资源B进行C操作,例如允许小王对工程管理模块进行管理操作。

  Ø 拒绝权限,明确拒绝身份A能够对资源B进行C操作,例如不允许小王对工程管理模块进行管理操作。

  Ø 如果一个系统中没有明确允许身份A能够对资源B进行C操作,那么并不代表系统就拒绝了身份A能够对资源B的C操作。

  图 4 允许权限与拒绝权限示意图

  1.6 传播权限与阻止权限

  Ø 传播权限,明确允许或拒绝身份A能够对资源B进行C操作,并将该描述已资源B为祖先向下传播,即身份A对资源B及B的子孙资源都能够进行C操作。

  Ø 阻止权限,即在传播源的子孙(某些)节点阻止祖先传播权限在那些节点的传播,即一旦在某节点阻止了祖先在该点的传播权限,则该阻止自动往下传播。

  图 5 传播权限与阻止权限图

  图 7 基于角色的权限控制模型图

  1.7 各种权限类型的联系与区别

  从概念上说,允许权限与拒绝权限是一对,而传播权限和阻止权限是一对。

  允许/拒绝权限是资源点上权限的横向描述,而传播/阻止权限是资源点上权限的纵向描述。

  拒绝权限与阻止权限的区别:如果在某个节点设置了对某个集合身份(例如群组)的拒绝权限,则该集合身份下的人,无论他们有多少其他身份,也无论这些其他身份是否设置了允许权限,最终都会因为拒绝权限而拒绝。而阻止权限与此不同,例如我们设置了对传播权限的一个阻止权限,同时在该节点又设置了允许权限,则我们先计算自身的拒绝与允许权限,然后才计算传播与阻止权限,因此阻止权限并不能阻止该节点的关联的允许或拒绝权限。

 2 权限控制模型

  2.1 主体-客体权限控制模型

  Ø 出现于早期的应用之中。在这里,主体相当于系统的访问者,客体相当于系统的资源。

  Ø 主体对于客体是否能够访问,一般是通过一个矩阵实现的。

  Ø 优点:授权关系明确,直截了当,存取都很容易。

  Ø 缺点:不能适应变化。

  图 6 主体-客体权限控制模型图

2.2 基于任务的权限控制模型

  Ø 任务是工作流程中的一个逻辑单元,一个流程一般包含一到多个任务。

  Ø 所谓基于任务,简单的说,就是主体在不同的任务中被许可的权限可能是不一样的,即使是在一个任务中,那么权限也会随着任务生命周期的不同而有所不同。

  Ø 因为权限随着任务和任务状态的不同而不同,所以这是一种动态的权限控制模型。

  Ø 优点:适合于与上下文环境关联紧密或者需要动态授权的应用系统,例如工作流引擎的权限控制。

  Ø 缺点:只适应于某些应用系统,绝大多数系统更为需要的是静态权限控制模型。

  2.3 基于角色的权限控制模型

  Ø 以角色为桥梁,将用户和资源连接起来,用户对某个资源是否能够访问,取决于该用户所对应的角色是否能够对某个资源访问。

  Ø 优点:适应变化。

  Ø 缺点:用户只能通过角色与资源打交道,那么为了某些特殊的用户,系统中不得不创建一些特殊的角色,这些角色实际上已经弱化为用户了。

  2.4 综合权限控制模型

  Ø 以角色为桥梁,将用户和资源连接起来,用户对某个资源是否能够访问,取决于该用户所对应的角色是否能够对某个资源访问。

  Ø 以群组为扩展,将某一组织或者群体下的用户统一授权,用户对某个资源是否能够访问,取决于该用户所对应的群组是否能够对某个资源访问。

  Ø 优点:授权方面、灵活。

  Ø 缺点:权限控制较难,计算复杂,运算效率低。

  图8 综合权限控制模型图

2.5 模型总体视图

  权限功能组件

  图10权限功能组件

  模型中重要的对象

  身份(Principal)

  图11权限的身份

资源(Resource)

  资源域(Resource Domain)

  Ø 提供资源域管理界面,通过该界面可以建立新的资源域,并向域中加入某类或多类资源,还可以配置资源的权限描述类

  Ø 资源域的对外服务是通过系统资源服务类实现的 ,这些服务包括:定位域中的资源、确定资源的组织方式等等

  操作(Action)

  Ø 支持操作之间的包含关系,而且支持包含关系的传递,即如果Action1>Action2,Action2>Action3,则Action1>Action3

  许可(Permission)

  Ø 许可,在Trix_X中是对某种资源关于权限方面的描述,例如该资源中包含哪些操作,这些操作之间的包含关系又是怎样的等等,这些都是在许可中定义的

  3 权限控制策略

  权限的优先级策略:对于同一个资源,拒绝权限>允许权限>继承权限。

组织结构分级管理策略,即组织机构中某个部门的管理员,只能对本部门及本部门的子孙部门的人员进行授权。

  权限的传播与阻止策略,该策略主要应用于树形资源的授权,目前尚未考虑组织结构这中树形结构对权限的影响。

  超级管理员策略:系统中一直存在一个超级管理员帐号,用于进行最高级。

  权限计算过程

  图12 权限计算过程图

4 权限控制体系功能描述

  以资源域为中心统一管理、配置资源及相关信息

  1) 资源域是系统中某类或某几类资源的集合。

  2) 提供资源域管理界面,通过该界面可以建立新的资源域,并向域中加入某类或多类资源,还可以配置资源的权限描述类。

  相当灵活的授权方式

  1) 以身份为中心授权:以身份为中心设置对哪些资源能够进行哪些访问等等,入口分散在人员、群组、组织机构的管理中。

  2) 以资源为中心授权:以资源为中心,授予哪些身份对该资源可以进行哪些访问等等,该方式又分为两种:

  (1) 资源集中授权:权限控制中心将各种资源域的资源以一系列树的方式集中在一起显示并进行授权。

  (2) 资源分散授权:任意一种资源,只要将资源标识(ID)、资源对象类(class全名)传给权限控制体系,则控制中心会弹出通用的授权界面,设置哪些身份对该资源可以进行哪些访问等等。

资源的权限描述可以通过可插拔的权限描述类来实现

  1) 权限描述类,主要负责描述该资源对外提供哪些操作以及其他一些信息等等。

  2) 在我们的体系中,每种资源都可以使用自己编写的权限描述类,也可以更换权限描述类。

  对于某种资源可能的操作,可以定义这些操作之间的包含关系。

  支持树形资源的授权,并支持权限的继承与传播。

  权限控制中心,在计算权限结果时,如果最终拒绝该请求,则会给出为什么不允许访问:是明确拒绝,还是因为不能计算出是否被拒绝而出于安全考虑才不允许访问的?如果是后者,对于关联资源的权限判断将很有帮助。

  尊重业务逻辑判断,支持业务对访问请求的优先判断

  在系统资源服务接口中定义了checkPermission方法,做为业务自身实现该接口操作后,在对某个请求进行访问控制时,我们现将控制权交给实现了该接口的业务自身,并传给业务足够的请求信息,业务自身对该请求进行业务逻辑判断后,可能会形成三种结果:

  1) 明确拒绝该请求,如果业务自身明确拒绝该请求,则权限控制体系将直接拒绝该请求,不再交给权限体系自身进行判断。

  2) 明确允许该请求 ,如果业务自身明确允许该请求,则权限控制体系将直接允许该请求,不再交给权限体系自身进行判断。

  3) 不确定是否允许访问,如果业务自身不知道是否允许或拒绝该请求,则权限控制体系会将控制权转交给权限判断中心进行进一步判断。

 5 权限存储

  权限的动作存储我们用位来表示,把所有可能的权限按一定的顺序排列,如添加、浏览、修改、删除...,用户的权限值为固定长度的字符串,如100010100001....01,从右起每一位对应一种操作权限,如果有这种权限,则此位的值为1,反之,则为0。当然,在数据库中,实际是存的2的n次方的计算结果数字,如0、1、2、4、8…,MS SQL数据库最大的数字是2的64次方,且保证尽可能多地存放权限,所以我们给权限进行了分组,每个64位的权限为一组,为了方便计算,组也是按2的n次方存放。同一组的权限位可按二进制进行与、或操作,只有该位为1表示有权限,否则没有权限。

  举例如下:

  权限排列表:添加、浏览、修改、删除,用户A有添加和浏览的的权限,则其权限值为0011,用户B有浏览和修改的权限则其权限值为0110,用户C有浏览和删除的权限则其权限值为1010,这样设计的好处为:当权限表中增加别的权限时,不会影响用户表或角色表,大大节省存储空间,并且提高查询效率;

  实际上数据库中表示二进制数据的方法是用数字类型字段来存储。

应用场景

  用户身份资源

  下面次序图描述了获取用户身份的各种场所,通过集合求和并排拆的方法求得用户的身份集合。

  图13 应用场景图

  用户权限

  下面此次序图描述了获取用户权限的综合应用, 用户权限包括应用资源、菜单、操作对象、对象的属性及对象的记录。

  图14 用户权限图

 7 实体类设计

  图15实体类 

 8 数据结构设计

  8.1 E-R关系图

  图16 E-R关系图

  8.2 主要数据实体说明

posted on 2009-01-12 18:18 suprasoft Inc,. 阅读(2412) 评论(3)  编辑  收藏 所属分类: Misc.

Feedback

# re: 权限控制与认证的解决方案(zz) 2009-06-03 22:10 殷文旭
这么好的帖子怎么能不顶一下,正愁没人教,天上掉下个粘豆包  回复  更多评论
  

# re: 权限控制与认证的解决方案(zz)[未登录] 2012-03-06 10:34 dd
如果有实现的代码更好  回复  更多评论
  

# re: 权限控制与认证的解决方案(zz) 2015-12-31 16:14 biscuit
辛苦了,写的很系统~  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航:
 
©2005-2008 Suprasoft Inc., All right reserved.