当前位置：首页 » 编程博文

开发技术指南» 文章正文

    引言： 前言：权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。

 

 

权限系统概要
前言: 权限往往是一个极其复杂的问题,但也可简单表述为这样的逻辑表达式:判断“who对what(which)进行how的操作”的逻辑表达式是否为真.针对不同的应用,需要根据项目的实际情况与具体架构,在维护性.灵活性.完整性等n多个方案之间比较权衡,选择符合的方案.目标:直观,因为系统最终会由最终用户来维护,权限分配的直观与容易理解,显得比较重要,系统不辞劳苦的实现了组的继承,除了功能的必须,更主要的就是因为它足够直观.简单,包括概念数量上的简单与意义上的简单还有功能上的简单.想用一个权限系统解决所有的权限问题是不现实的.设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑,而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路.扩展,采用可继承在扩展上的困难.的group概念在支持权限以组方式定义的同时有效避免了重定义时现状:对于在企业环境中的访问控制方法,一般有三种:1.自主型访问控制方法.目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(acls).2.强制型访问控制方法.用于多层次安全级别的军事应用.3.基于角色的访问控制方法（rbac）.是目前公认的解决大型企业的统一资源访问控制的有效方法.其显著的两大特征是:1.减小授权管理的复杂性,降低管理开销.2.灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性.名词:粗粒度:表示类别级,即仅考虑对象的类别(the type of object),不考虑对象的某个特定实例.比如,用户管理中,创建.删除,对所有的用户都一视同仁,并不区分操作的具体对象实例.细粒度:表示实例级,即需要考虑具体对象的实例(the instance of object),当然,细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例.比如,合同管理中,列表.删除,需要区分该合同实例是否为当前用户所创建.原则:权限逻辑配合业务逻辑.即权限系统以为业务逻辑提供服务为目标.相当多细粒度的权限问题因其极其独特而不具通用意义,它们也能被理解为是“业务逻辑”的一部分.比如,要求:“合同资源只能被它的创建者删除,与创建者同组的用户可以修改,所有的用户能够浏览”.这既可以认为是一个细粒度的权限问题,也可以认为是一个业务逻辑问题.在这里它是业务逻辑问题,在整个权限系统的架构设计之中不予过多考虑.当然,权限系统的架构也必须要能支持这样的控制判断.或者说,系统提供足够多但不是完全的控制能力.即,设计原则归结为:“系统只提供粗粒度的权限,细粒度的权限被认为是业务逻辑的职责”.需要再次强调的是,这里表述的权限系统仅是一个“不完全”的权限系统,即,它不提供所有关于权限的问题的解决方法.它提供一个基础,并解决那些具有“共性”的(或者说粗粒度的)部分.在这个基础之上,根据“业务逻辑”的独特权限需求,编码实现剩余部分(或者说细粒度的)部分,才算完整.回到权限的问题公式,通用的设计仅解决了who+what+how 的问题,其他的权限问题留给业务逻辑解决.概念:who:权限的拥用者或主体（principal.user.group.role.actor等等）what:权限针对的对象或资源（resource.class）.how:具体的权限（privilege, 正向授权与负向授权）.role:是角色,拥有一定数量的权限.operator:操作.表明对what的how 操作.
...   下一页

» 本期热门文章：

· 热门栏目：

» 相关精选文章

» 其它相关：