2。访问控制信息是由具体创建数据的模块来维护；而非人员权限模块来负责管理；

这里有些疑问，除了角色列表外，应该还有其他访问控制信息为权限模块所知晓，除非权限被简单化
无论是具体模块，还是权限模块，都必须知道一些共同的规则才能去维护或审核，那么这些地方应该进行设计以反映到同一的接口上，否则最终实现还是难以控制，这也就反映到标准上的概念。

当然不是一一对应，因为本身角色和权限点就是多队多的关系，庆祝一我上问用的词汇，角色列表，是列表！
也就是说把角色和权限点的多对多关系保存在资源处；

嗯，这里我稍微有些误解，但主要我考虑的还不是这个问题。我曾经接触过据说是日本政府资助的一个访问控制实现，里面有角色和组的概念，也有类似的列表。他的设计应该也是比较完善的，（日本人的东西大多如此，不管其他好坏，保证做出的东西的确是能用的），但我想在具体项目中应用还是会有很多问题的。静态的权限系统和变化的世界是不相配合的，所以对象的概念要被提出。

的确我的想法还是泛泛而谈，具体实施起来会有问题的，标准只是把成熟的想法设计在给定的假设下给确定下来，所以需要了解问题，提出假设，才有标准。目前对问题的了解似乎还有所欠缺的地方。希望这样的讨论会让东西变得明晰起来。

huzhigang 提到的OpenSymphony - OSAccess
是一种GROUP BASED ACCESS CONTROL,是一种逻辑相对简单的访问控制。“OSAccess is a centralized Entitlement Engine”这一句话就定义了它根本就不考虑数据权限；

而且基于组的考虑有点初级了，无法解决复杂的人员机构关系；
继续关注。

对于数据而言，自己本身就是权限点；如果还不够细就要在进行区分，例如数据的修改，读去就可以看成是不同的权限点；
然后纪录角色跟这些权限点关系；

上面是具体的做法，这些做法的出发点是访问信息的分布，因为这些数据是超出访问控制模块控制的范围的；
由数据的制造者按照访问控制的规范（就象是达成某种契约）来记录访问控制信息；

本贴描述的模型的核心就是角色，其它的对象通过关联；
原来的教训是对象之间关联越多，耦合越紧，功能更改付出的代价越大。

如你所说，数据的权限还要细分，比如读取，修改，删除等等，所以要附加更多的信息，这里需要进行一定的研究。

用数据来关联，的确可以降低耦合性，所以很多web开发都是只管访问数据库的。但也有可能不是没有权限都有对应的数据记录关联的，或者不是关联到一行数据上，还有可能功能和数据之间的映射不是那么简单，比如不能访问，不能都说成不能操作某条数据记录。

数据的制造者去关心数据权限，如果权限比较复杂，可能就实现不了，而且也使得数据记录本身变得复杂起来，不符合面向方面的特性，而且实际中能否强迫应用是一个问题。

按照数据想法，权限模块本身能做的工作很少，说到底还是一些判断函数的调用，而这些结果和数据权限的划分是对等的，不能生成更高层次的权限出来，少写的代码十分有限。

所以数据作为契约本身是一种极化模式，反之对象之间是可以不用关联，但可以设计单独的权限系统，让对象都从权限系统中生成，这样就强迫所有的设计会按照共同的标准进行，而不用担心细节问题。

回复一下，不考虑部门是不可能的

举个现实例子

一个公司，有很多部门，每个部门都有很多人员，某些人员可能有几个部门的权限等等，只用role的化肯定会产生很多麻烦，还有部门级别之间的从属关系，如果只是user，role，那么肯定不能满足真真系统的需要，大家应该更实际一点，想象一下自己公司内部结构组织就会有了解了,某个RBAC的规范只适合于特定的系统，不能包罗万象的。

还有，很多公司的组织结构不同，那么权限系统也不同，很难有一个统一的标准，我很想知道怎么解决这点问题。。。真的很难

例如举例，500强公司和只有几个人的公司，那么肯定系统差别很大

好好想想操作系统的权限就行了。至于资源点和行为点的操控也没有什么不同。角色更不是什么新东西。
其实权限本来就没有什么东西，很小的一块。标准不标准地，没什么意义。相反倒是资源点和行为点的组织倒是很值得注意和小心。

我考虑部门了，请再仔细看看。

我设想部门是角色的集合。然后角色再跟人关联。

例如公共关系部有 所属人员角色 这个角色关联了所有这个部门的人。

建议部门和角色分开，比较清晰，也符合从现实抽象出来的模型。

角色和部门确实应该分开，不仅符合现实，而且其中的好处其中就有减少实施的繁琐度。

我们的系统在几年前就已经用到了这种模型，当然根据项目的情况也有所不同，而前不久又进行的进一步改进。个人觉得这个模型的中心应该是角色，角色管理着资源。这里的资源包括操作和数据等等所有需要管理的东西。操作可以分类也可以不分类，根据项目需要吧。操作与机构（我叫做节点，机构设置一般都是树型的，其中每个机构就是一个节点）构成一个权限点。同理，如果可以的话，数据也可以分类，这样数据也可以和节点构成一个权限点。这样角色管理就是对权限点的管理。当然权限点也要分类，操作可以分为使用、授权和使用并授权；对数据的访问也可以分为读、写、执行等。
这样就可以通过角色来管理所有的资源。同时角色需要定义在某个节点下，表明该角色属于某个节点，但因为权限点是资源节点对结构，所以某节点下的角色也可以实现跨节点的操作和数据访问。
上面是对我当前用到的模型的阐述，不过他也存在一些优缺点。
优点：以角色为核心，实现对资源的统一管理，管理起来方便清晰
缺点：对权限的一些变动就可能需要增加角色，容易造成角色泛滥

大家怎么不提职务呀，我想，职务与角色因该有区别吧，在中国，职务的概念是很重要的，职务结构是一棵树，角色的结构也是一棵树吗？，在工作流办理中，可能下一个办理是选择上级职务，如果是角色，是选择上级角色吗？

我目前是把职务看成就是角色。

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

的确如此，在现实的管理要求中，对权限点的划分是非常细小的，角色与权限点的多对多的关系，引申出来的就是众多的角色要求，那么最终，会不会出现一个人员就是一个具体的角色，因为每一个人的权限都不一样。
A采购员可以购买I区的原料，B采购员可以购买II区的原料，C采购员可以购买I、III区的原料……

qq