[导入]权限系统(1)--基本模式 (转)
2009-07-03 08:53
239 查看
在系统中发生的事情,抽象的说都是某个主体(subject)在某个资源(resource)上执行了某个操作(operation)。
subject --[operation]--> resource
所谓权限管理,就是在这条信息传递路径中加上一些限制性控制。
主体试图去做的 limited by 系统允许主体去做的 = 主体实际做的。
可以看到,权限控制基本对应于filter模式。subject试图去做的事情应该由业务逻辑决定,因而应该编码在业务系统中。
先考虑最粗粒度的控制策略,控制点加在subject处,即无论从事何种操作,针对何种资源,我们首先需要确认subject是受控的。只有通过认证的用户才能使用系统功能,这就是authentication。boolean isAllowed subject)
稍微复杂一些,控制可以施加在subject和operation的边界处(此时并不知道具体进行何种操作),称为模块访问控制,即只有某些用户才能访问特定模块。isAllowed(subject, operation set)
第三级控制直接施加在operation上,即操作访问控制。operation知道resource和subject(但它尚没有关于resource 的细节知识),我们能够采取的权限机制是bool isAllowed(subject, operation, resource), 返回true允许操作,返回false则不允许操作。
最简单的情况下,subject与resource之间的访问控制关系是静态的,可以直接写成一个权限控制矩阵
for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1
isAllowed(subjectA, resourceA)恒等于true
如果多个operation的权限控制都可以通过这种方式来表示,则多个权限控制矩阵可以叠加在一起
for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11
当subject和resource的种类很多时,权限控制矩阵急剧膨胀,它的条目数是N*M。很显然,我们需要进行矩阵分解。这也是最基本的控制手段之一: 在系统中增加一个瓶颈,或者说寻找到隐含的结构。
subject_resource = subject_role * role_resource
这样系统权限配置条目的数量为 N*R + R*M, 如果R的数目远小于subject和resource,则实现简化。这称为RBAC(role based access control),它的一个额外好处是权限系统的部分描述可以独立于subject存在,即在系统中没有任何用户的时候,通过角色仍然可以表达部分权限信息。可以说角色是subject在权限系统中的代理(分解)。
有时候引入一个瓶颈还不过瘾,有人引入组的概念,与role串联,
subject_resource = subject_group_role * role_resource
或着group与role并联,
subject_resource = subject_group * group_resource
与role稍有不同,一般情况下group的业务含义更加明显,可能对应于组织结构等。将组织机构明确引入权限体系,有的时候比较方便,但对于权限系统自身的稳定性而言,未见得有什么太大的好处。并联模式有些多余,串联模式又过于复杂,细节调整困难,特别是多条控制路径造成的冲突情况。一般情况下,我不提倡将group引入权限控制中。
比操作控制更加深入的控制就是数据控制了,此时需要对于resource的比较全面的知识。虽然表面上,仍然是
boolean isAllowed(subject, operation, resource),但控制函数需要知道resource的细节。例如行级控制(row-level)或者列级控制(column-level)的实现。因为我们一般情况下不可能将每一个条目都建模为独立的resource,而只能是存在一个整体描述,例如所有密级为绝密的文档。在witrix平台中,数据控制主要通过数据源的filter来实现,因为查询条件(数据的定位条件)已经被对象化为Query类,所以我们可以在合适的地方自由的追加权限控制条件。
以上的讨论中,权限控制都是根据某些静态描述信息来进行的,但现实世界是多变的。最简单的,当subject从事不同业务时,对应于同一组资源,也可能对应的权限控制并不同(在witrix平台中,对应于IDataSource的模式切换)。更复杂一些, 在不同的时刻, 我们需要根据其他附加信息来作出是否允许操作的判断, 即此时我们权限设置的不仅仅是一些静态的描述信息, 而是一个完整的控制函数, 这就是所谓的工作流权限控制,一种动态权限控制.
原文出处 :http://canonical.javaeye.com/blog/33848
subject --[operation]--> resource
所谓权限管理,就是在这条信息传递路径中加上一些限制性控制。
主体试图去做的 limited by 系统允许主体去做的 = 主体实际做的。
可以看到,权限控制基本对应于filter模式。subject试图去做的事情应该由业务逻辑决定,因而应该编码在业务系统中。
先考虑最粗粒度的控制策略,控制点加在subject处,即无论从事何种操作,针对何种资源,我们首先需要确认subject是受控的。只有通过认证的用户才能使用系统功能,这就是authentication。boolean isAllowed subject)
稍微复杂一些,控制可以施加在subject和operation的边界处(此时并不知道具体进行何种操作),称为模块访问控制,即只有某些用户才能访问特定模块。isAllowed(subject, operation set)
第三级控制直接施加在operation上,即操作访问控制。operation知道resource和subject(但它尚没有关于resource 的细节知识),我们能够采取的权限机制是bool isAllowed(subject, operation, resource), 返回true允许操作,返回false则不允许操作。
最简单的情况下,subject与resource之间的访问控制关系是静态的,可以直接写成一个权限控制矩阵
for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1
isAllowed(subjectA, resourceA)恒等于true
如果多个operation的权限控制都可以通过这种方式来表示,则多个权限控制矩阵可以叠加在一起
for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11
当subject和resource的种类很多时,权限控制矩阵急剧膨胀,它的条目数是N*M。很显然,我们需要进行矩阵分解。这也是最基本的控制手段之一: 在系统中增加一个瓶颈,或者说寻找到隐含的结构。
subject_resource = subject_role * role_resource
这样系统权限配置条目的数量为 N*R + R*M, 如果R的数目远小于subject和resource,则实现简化。这称为RBAC(role based access control),它的一个额外好处是权限系统的部分描述可以独立于subject存在,即在系统中没有任何用户的时候,通过角色仍然可以表达部分权限信息。可以说角色是subject在权限系统中的代理(分解)。
有时候引入一个瓶颈还不过瘾,有人引入组的概念,与role串联,
subject_resource = subject_group_role * role_resource
或着group与role并联,
subject_resource = subject_group * group_resource
与role稍有不同,一般情况下group的业务含义更加明显,可能对应于组织结构等。将组织机构明确引入权限体系,有的时候比较方便,但对于权限系统自身的稳定性而言,未见得有什么太大的好处。并联模式有些多余,串联模式又过于复杂,细节调整困难,特别是多条控制路径造成的冲突情况。一般情况下,我不提倡将group引入权限控制中。
比操作控制更加深入的控制就是数据控制了,此时需要对于resource的比较全面的知识。虽然表面上,仍然是
boolean isAllowed(subject, operation, resource),但控制函数需要知道resource的细节。例如行级控制(row-level)或者列级控制(column-level)的实现。因为我们一般情况下不可能将每一个条目都建模为独立的resource,而只能是存在一个整体描述,例如所有密级为绝密的文档。在witrix平台中,数据控制主要通过数据源的filter来实现,因为查询条件(数据的定位条件)已经被对象化为Query类,所以我们可以在合适的地方自由的追加权限控制条件。
以上的讨论中,权限控制都是根据某些静态描述信息来进行的,但现实世界是多变的。最简单的,当subject从事不同业务时,对应于同一组资源,也可能对应的权限控制并不同(在witrix平台中,对应于IDataSource的模式切换)。更复杂一些, 在不同的时刻, 我们需要根据其他附加信息来作出是否允许操作的判断, 即此时我们权限设置的不仅仅是一些静态的描述信息, 而是一个完整的控制函数, 这就是所谓的工作流权限控制,一种动态权限控制.
原文出处 :http://canonical.javaeye.com/blog/33848
相关文章推荐
- 网络博客系统的基本模式
- 分布式系统中的几种数据备份模式. 数据可靠性(基本,),数据一致性(脑裂问题,高可靠性容灾性),数据可用性(数据拆分,读写分离),系统扩展性.
- Linux系统下设置USB设备用户权限的基本方法
- (.net+MVC)导入资源功能的实现---权限系统
- 权限系统基本分析
- 基于RBAC模式的权限管理系统设计概要
- Java学习笔记四。设计模式、基本数据类型、包装类、异常、断言、包、访问权限、命名规范、jar
- 走火入魔权限管理系统、插件模式集成的实现参考
- [导入]如何在64系统上监视32位模式下ASP.NET程序的性能
- 利用通用权限管理系统底层解决数据从不同库的导入导出问题
- Eclipse如何快速调试系统App(具有系统权限的Android App)即Eclipse导入系统签名快速调试系统App
- oracle数据库部分基本操作(表数据恢复,创建用户并加权限,数据导入导出)
- 黑马程序员--高新技术--静态导入,基本数据类型拆箱与装箱,享元设计模式
- Linux ubuntu 修改了locale文件后系统无法启动进入系统修复模式变成无权限操作locale文件
- [导入]用户权限系统设计方案
- Linux系统管理_基本权限和归属-Redhat Enterprise 5
- Android系统架构基本模式解析
- Android系统架构基本模式解析
- ABP module-zero +AdminLTE+Bootstrap Table+jQuery权限管理系统第十三节--RBAC模式及ABP权限管理(附赠福利)
- Eclipse如何快速调试系统App(具有系统权限的Android App)即Eclipse导入系统签名快速调试系统App