最近对就有系统人员权限升级计划――也谈人员权限的设计。

04-04-16 dunel
前言:

人员、机构、角色、权限对象间组织关系的重新抽象;

人员、机构、角色、权限;

这四个经过抽象的对象原型经过事实证明还是比较成功的;

这几个对象不会有大的变动;

但是实际中也碰到了问题,就是这些对象之间关系的不确定性;

下面描述以下四个对象新的关系结构;

1 核心思想:

1。人员在系统中总是扮演某种角色的;

例如:小张在属于办公厅这个部门,以前我们都倾向于认为办公厅聚合了小张。

其实考察一下实际情况,办公厅下面有个办公厅人员这个角色,而小张只是扮演了这个角色而已;

考虑一下如果当小长被调动另外一个部门时候那种抽象更容易处理。

2。业务逻辑希望面对的是系统中的角色,而非扮演角色的具体的人。

例如:以工作流示例,一个公文的下一步流转的对象是组织部部长,他不关心谁扮演这个部长,人员权限模块知道就行了。

2 抽象关系描述:

.人员和机构之间的松耦合(通过角色耦合)

目的:改变糟糕地人员和机构之间的强聚合关系。

人员和部门通过角色进行耦合;

人员和部门的关系可以容易的变化,不会产生大的影响。

.人员和角色间变成强聚合关系;

目的:强调人员在系统中必须扮演角色,起码扮演某个机构的人员这个角色;

人员的角色又可以同时扮演的,也有互相排斥的。

排斥的角色就是不能同时扮演的,登录以后可以选择的角色;

由管理员规定人员的那些角色是相互排斥的;

.机构和权限点之间没有直接关系;

目的:让机构的抽象更清晰化,机构和权限的关系通过角色体现;

.机构和角色之间强聚合关系;

目的:明确部门的作用是行使某种特定职能的。

说明:

部门和部门之间还有从属关系;

部门可以专门设置部门管理员用于管理下级的机构和人员,使分级管理在模型上成为可能;

部门拥有的角色有写是系统规定的,如:部门人员,部门管理员;

部门可以自定义自己的角色,并由部门管理员管理;

.角色之间的继承关系;

目的:更好的处理角色和权限点之间的关系;

说明:

角色之间拥有继承关系如上图所示。

可以被继承的角色是由系统管理员制定的,部门管理员不能制定;

3 总结:

经过考虑,我认为 人员、机构、角色、权限 的关系应该做成可以改变的插件,系统初始时候进行选择不同组织方式;

也就是说,上文描述的 人员、机构、角色、权限 的关系还有原有关系都做成的插件,并不抛弃原有的人员权限关系。

    

dunel
2004-04-16 17:46

dunel
2004-04-16 17:53
与RBAC向做的设想就是人员和权限的直接耦合关系。

在应用中经常会出现某个人就是要比其他人多出来一个权限,而且这样的情况非常多,如果每次都为这种情况做一个角色的话,基本上会造成角色的泛滥。

不知道大家有什么好的设想,或者解决方案。

dunel
2004-04-19 16:32
最近研究了RBAC的规范,RBAC没有提到关于人员是如何组织的,更关注与资源的控制。但是我认为人员机构的管理是应该一起关注的,所以做出了这样的设计。

大家给提提意见吧。

dunel
2004-04-20 13:28
ROLE BASE ACCESS CONTROL

最近研究了RBAC的标准,这个标准刚刚成为美国国家标准。http://csrc.nist.gov/rbac/

下面是我的一些心得和笔记,希望能有用处。

1. RBAC的中心思想就是通过角色来做到用户和权限点的关联;

2. 扩展RBAC角色是可以继承的。

一般继承,就是多继承,一个角色可以继承多个角色;

限制继承就是单继承,一个角色只能继承一个角色;

3. 静态职责分离Static Separation of Duty --SSD是说,一个人一次只能扮演一个角色;

经常在系统的行政角色上实施SSD;这个限制强加在人员分配的情况下的;

4. 动态职责分离 Dynamic Separation of Duty C DSD就是:timely revocation of truest,就是能给人员分配冲突的角色,但是一个人每次只能扮演其中的一个;原来的设想中涉及到了DSD就是让人选择角色进入;

猜你喜欢
9Go 1 2 3 4 ... 9 下一页