|
这个主题共有 39 回复 ／ 3 页 [
1 2 3
下一页
]
|
|
|
|
|
|
最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月16日 17:43
|
回复
|
|
前言：
人员、机构、角色、权限对象间组织关系的重新抽象；
人员、机构、角色、权限；
这四个经过抽象的对象原型经过事实证明还是比较成功的；
这几个对象不会有大的变动；
但是实际中也碰到了问题，就是这些对象之间关系的不确定性；
下面描述以下四个对象新的关系结构；
1 核心思想：
1。人员在系统中总是扮演某种角色的；
例如：小张在属于办公厅这个部门，以前我们都倾向于认为办公厅聚合了小张。
其实考察一下实际情况，办公厅下面有个办公厅人员这个角色，而小张只是扮演了这个角色而已；
考虑一下如果当小长被调动另外一个部门时候那种抽象更容易处理。
2。业务逻辑希望面对的是系统中的角色，而非扮演角色的具体的人。
例如：以工作流示例，一个公文的下一步流转的对象是组织部部长，他不关心谁扮演这个部长，人员权限模块知道就行了。
2 抽象关系描述：
.人员和机构之间的松耦合（通过角色耦合）
目的：改变糟糕地人员和机构之间的强聚合关系。
人员和部门通过角色进行耦合；
人员和部门的关系可以容易的变化，不会产生大的影响。
.人员和角色间变成强聚合关系；
目的：强调人员在系统中必须扮演角色，起码扮演某个机构的人员这个角色；
人员的角色又可以同时扮演的，也有互相排斥的。
排斥的角色就是不能同时扮演的，登录以后可以选择的角色；
由管理员规定人员的那些角色是相互排斥的；
.机构和权限点之间没有直接关系；
目的：让机构的抽象更清晰化，机构和权限的关系通过角色体现；
.机构和角色之间强聚合关系；
目的：明确部门的作用是行使某种特定职能的。
说明：
部门和部门之间还有从属关系；
部门可以专门设置部门管理员用于管理下级的机构和人员，使分级管理在模型上成为可能；
部门拥有的角色有写是系统规定的，如：部门人员，部门管理员；
部门可以自定义自己的角色，并由部门管理员管理；
.角色之间的继承关系；
目的：更好的处理角色和权限点之间的关系；
说明：
角色之间拥有继承关系如上图所示。
可以被继承的角色是由系统管理员制定的，部门管理员不能制定；
3 总结：
经过考虑，我认为 人员、机构、角色、权限 的关系应该做成可以改变的插件，系统初始时候进行选择不同组织方式；
也就是说，上文描述的 人员、机构、角色、权限 的关系还有原有关系都做成的插件，并不抛弃原有的人员权限关系。
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月16日 17:46
|
回复
|
|
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月16日 17:53
|
回复
|
|
与RBAC向做的设想就是人员和权限的直接耦合关系。
在应用中经常会出现某个人就是要比其他人多出来一个权限，而且这样的情况非常多，如果每次都为这种情况做一个角色的话，基本上会造成角色的泛滥。
不知道大家有什么好的设想，或者解决方案。
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月19日 16:32
|
回复
|
|
最近研究了RBAC的规范，RBAC没有提到关于人员是如何组织的，更关注与资源的控制。但是我认为人员机构的管理是应该一起关注的，所以做出了这样的设计。
大家给提提意见吧。
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 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就是让人选择角色进入；
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月22日 09:35
|
回复
|
|
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月22日 11:11
|
回复
|
|
我非常赞同dunel的分析，特别是认真强调了角色，以前很多帖子都似乎不愿意正视角色，我个人不是很认可。
我一直推荐引入角色概念，在这方面也和很多人发生过争执，看到一个大型OA系统企图以用户组group替代角色，非常痛心，非得走弯路，系统复杂撞墙了才回头啊。
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月22日 23:52
|
回复
|
|
see IBM Tivoli Access Manager.
something your can use directly.
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月23日 08:50
|
回复
|
|
|
opensymphony下的osaccess和osuser个人认为很不错。大家可以参考一下
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月24日 14:16
|
回复
|
|
dunel的论述确实有着重要的现实意义,我所经历的项目中对于组织结构的设计,采用了类似的思想(但没有继承).
就目前的业务抽象能力,技术的发展及客户需求来看,这是个应该正视和面对的问题,如果确实抽象的完善,可靠,
扩展性强,对于应用软件行业的发展的贡献是重大的,解放设计人员,开发人员,降低成本,提高效率,缩短开发周期.
感谢,dunel先生的精彩论述!
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月25日 13:02
|
回复
|
|
这些倒不是很难的问题，怎样在系统中定义权限点是比较难的，也就是＇授权模式＇．
1.往往一些系统的授权模式很复杂．
像：＇某某对金额<40000的订单有察看权限＇，＇某某对客户地址位于华东区的订单拥有修改权限＇等等，在一些系统的需求中就有这些很复杂的授权模式
2.权限是要分类的：
可以分为功能权限／系统权限／数据权限
这个数据权限是问题的重点，往往处理不好会在权限校验的时候
产生性能问题．
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月26日 02:52
|
回复
|
|
我也赞同以角色来划分权限，不过对于个别权限的增减可能还得需要在人员上直接控制操作起来比较方便，我看到过一些商业系统的实现就是如此的。
其实我认为角色并不是因为开发人员的需要而提出来的，而是为了管理上的便利才有的。至于组模式，那是在传统文件系统权限概念模式上扩展的，并不适合应用模式，banq说的很现实。
还有上面人提出的功能点的问题同样切中要害，所以面向开发者的权限系统不仅仅是提出面向功能的角色就完事的，而是需要一个面向对象的权限设计。我在考虑这方面的问题，有想法推出通用些的方案。
|
|
|
|
|
|
Re: 最近对旧有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月26日 17:27
|
回复
|
|
我原来以为不会有人关注我这个贴子了，没想到还是由同道中人的；
看到大家这么说，我就针对大家一致比较头疼的功能权限和数据权限的处理方案分别阐述一下；
最后再提一些大家可能会碰到转授权的问题；
也算是我最近对人员权限部分重新建模的一个总结；
一：功能权限数据权限的差别，及解决方案；
访问控制信息：就是纪录用户对资源操作的允许权限；
访问控制信息如何处理的问题；
请允许我抑制内心的激动直接说出解决方案，数据权限是访问信息分布，功能权限是访问信息集中；您要是真的做过可能已经能够了解了；
数据权限：凡是要求被我控制的数据我也有要求，我要求你必须增加一个字段记录我的访问控制信息，比如角色id列表（最好用角色，目前也在考虑中）；其实是不是数据库的某条纪录不是重点，重点是访问控制信息存放在要被控制的资源处，人员权限模块只负责根据这些访问信息给出答案；
你可能会问：数据权限一般都不会有人机界面来处理访问控制信息，请别急再下面的功能权限会阐述；
功能权限：这个比较好做，就是系统运行期规定好的权限集合，当然运行其可以添加，但是实际意义不大（运行期的添加的功能权限谁给你实现去？除非你运行期添加模块，牛；也能实现）；
其实我是想说一个问题，就是开发人员的功能权限视图和人员权限模块的功能权限视图的不一致；总不能系统把所有未来的功能模块的权限点也都加上吧！？
所以涉及到一个功能权限点的收集装置，收集装置回处理提交的外部权限点名称然后根内部的权限点ID做Mapping，这其实就一个系统权限点的扩展模块；这样模块就不必提及系统内部的权限点ID，同样的角色也可以这样处理这就回答了上面提出的问题；
二：转授权的处理方式；
此种情况在转授形成授权链；
出现了链的层次深度问题，同样回收时候也碰到回收层次深度问题；
这是需要避免的，可以这样设想，b有权把a->b的授权变成a->c的授权而不应该是a->b,b->c这样的概念。
这个处理方案的核心思想就是转授权的两点化而非职责链化。
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月26日 18:17
|
回复
|
|
按数据权限的规划的确更加接近解决问题了，这也就是我提出的面向对象的观点，但问题是访问控制信息究竟应该包含什么样的内容，这个恐怕就不是一两个字段可以解决的。一个数据可以被多个实际使用者访问，而这些使用者可能属于相同或者不同的角色，也就是说不是和角色一一对应的，当然如果你要这么做也可以，但想象一下，不难发现角色就失去了原本的意义。说到底，对操作用户可见的角色是方便他们使用，而不是解决问题的所有内涵。
如果权限模块做的好，上面的问题当然可能已经解决，或者在实现系统中已经解决，但如果大部分实现是在权限内部，不难想象，这很难做到推而广之，一个没有标准可以遵循的实现，就算没有因为过分陷入细节而复杂也不可能方便重用的。
真正通用的实现，必然是动态可配置的系统，而真正与细节相关的内容，应该由用户自行决定如何实现的。
|
|
|
|
|
|
Re: 最近对就有系统人员权限升级计划――也谈人员权限的设计。
|
发表: 2004年04月27日 09:51
|
回复
|
|
按数据权限的规划的确更加接近解决问题了，这也就是我提出的面向对象的观点，但问题是访问控制信息究竟应该包含什么样的内容，这个恐怕就不是一两个字段可以解决的。
----------------------------------------------------------------
1。我认为应该包含角色列表信息，就是应该保存这样的字符串"组织部长,计划科科长……"这样的字符串；为什么呢？
因为我们分析一下数据权限的要求“组织部长能看到……”都是围绕着角色来定义的，其实这里保存的就是角色跟权限点的对应关系，一条数据就是权限点，而访问控制信息就是角色和权限点的关联关系；
2。访问控制信息是由具体创建数据的模块来维护；而非人员权限模块来负责管理；
因此我认为保存角色列表信息足矣，当然不是非要局限于一两个字段这样的狭隘概念上；
举个实例：windows的文件权限；
----------------------------------------------------------------
一个数据可以被多个实际使用者访问，而这些使用者可能属于相同或者不同的角色，也就是说不是和角色一一对应的，当然如果你要这么做也可以，但想象一下，不难发现角色就失去了原本的意义。说到底，对操作用户可见的角色是方便他们使用，而不是解决问题的所有内涵。
----------------------------------------------------------------
你说得很对，正是我要说明的；
当然不是一一对应，因为本身角色和权限点就是多队多的关系，庆祝一我上问用的词汇，角色列表，是列表！
也就是说把角色和权限点的多对多关系保存在资源处；
----------------------------------------------------------------
如果权限模块做的好，上面的问题当然可能已经解决，或者在实现系统中已经解决，但如果大部分实现是在权限内部，不难想象，这很难做到推而广之，一个没有标准可以遵循的实现，就算没有因为过分陷入细节而复杂也不可能方便重用的。
真正通用的实现，必然是动态可配置的系统，而真正与细节相关的内容，应该由用户自行决定如何实现的。
----------------------------------------------------------------
部分同意你最后这句“真正通用的实现，必然是动态可配置的系统，而真正与细节相关的内容，应该由用户自行决定如何实现的。 ”
最后一句就涉及到一个范围问题，就是所谓有所为，有所不为；我很同意你的关于标准的论点，但是据我所知目前没有一个国际通行的ACCESS CONTROL的体系什么GROUP BASED ACCESS CONTROL,MAC,DAC等等一大堆，甚至什么ROLE BASE ACCESS CONTROL也是刚刚才成为美国的国家标准；而RBAC里面提到概念竟然是我都想到的东西；我不禁有些痛心；
我们中国人是聪明的，可是我们自己的标准太少；说到这儿就想起了目前火热的关于汽车的自主知识产权的讨论：是引进好还是自己设计生产好；
我的立场是自己设计生产！同样对于这样一个没有完整体系的领域,是我们没有什么标准可以遵循，但是现在有一个机会摆在面前，如果们能够提出一整套标准为什么非要遵循别人的呢？好题外话到此为止；
TIG的提议很中肯，能看出是在考虑；但是我觉得有些外延的模糊化，就是没有给自己的考虑定义一个外延，还有没有进行渐进式的考虑；这样容易让自己的想法无法具体化，尤其最后的标准的理论；
先这些
----------------------------------------------------------------
|
|
|
|
|
|
这个主题有 39 回复 ／ 3 页 [
1 2 3
下一页
]
|
|
|
注册
登陆
上一主题
下一主题
