pow2ACL这个东东与我们上面讨论的思路是基本一致的，可惜不是基于J2EE的。
去年我做了一个很简单的权限管理系统( JsunAuth)
系统中只有三个对象: user, resource , privilege ，权限只有“许可”一种。
最近正在做升级版，系统参照windows2000的权限系统，其中有些想法和楼上几位不谋而合（其实模式就那几种）
目前主要考虑的问题是：
1组能否包含组；2.权限的包含和排斥；3；基本权限和用户自定义权限的组合；
希望和各位多交流
aryang@vip.sina.com
你又出现了？
你的主页一直没更新，所以我以为你转行了，，呵呵。
组当然应该包含组；
权限应该可以包含和排斥，
这两个功能估计你要等你的3.0版本出来才加上，一开始不用考虑这些。
但必须在设计上留下余地，树形结构组织可以适应这样的架构。
我的主页第一次上传后在没有更新，一年来过的浑浑僵僵，比起banq兄来真是太惭愧了。
曾经是Jive社区里第44个注册的用户，也是很早向国内朋友介绍Jive的人，但后来却一直在一家小公司忙于一些事务性的工作，钱没挣到技术也一落千丈！
我打算年后离开西安，呼吸一些新鲜空气，不至于让触角锈掉！
向banq学习！
d
dfssdfsdf
有关权限管理的构成已经基本解决了，接下来是如何使用权限管理？
方案：
1。象iceant 那样
------------------------------------
>>>6. User 进到系统，在它的可访问资源列表上，会出现"部门新闻发布"的链接.
>>>7. User 点击 "部门新闻发布"的链接, 根据 Creator 的实现，系统会检查
>>>[1] 当前用户是否拥有发布权限
>>>[2] 当前用户的发布权限是否与能操作正在访问的资源.
------------------------------------
这里有个问题：资源可能是分级的（树型），可否考虑过？
2。资源列表已固定，在每个资源前加判断，如果有权限则显示该资源，如果无权限则不显示；
3。资源列表已固定，在用户点击链接后加判断
你的意思是说，假如 Resource 是 tree type 的.
将 Resource 中的某个节点(非叶子节点)的权限分给用户后，
用户将拥有对该 Resource node 下的所有 child nodes 同样的权限?
这让我想起了操作系统里对文件夹权限的分配.
非常感谢你提出来的这个想法。我是没有想到~!!!
========================================================
理想的状态，当然是 2,3 一起做。
如果是我来做，因为我的视图使用的是面向对象的方式，所以，我可以做一个 View 的基类.在基类里完成 common 的 securityCheck().
其它的视图都 extend 这个 BaseView, 当需要做特殊的权限处理时，可以重写 securityCheck() 方法.
这里有另外的问题
什么叫做“新闻发布的权限”？这样的权限是如何定义的？
我的理解，新闻发布的权限包括两类，一类是你有运行这个function的权限，另外一类是，你对新闻发布所操作的资源的权限，这类操作资源的权限在我看来十分的复杂，一般的理解是对新闻发布所操作的资源的增、删、改、查的权限，但仔细考量应该还有对满足什么样条件的记录有增、删、改、查的权限，甚至可能还需要定义，特定用户对记录的增、改是否有取值的限制。例如某个用户只能够查询本部门的资源，这种情况就是对满足特定条件的记录有增、删、改、查的权限。又如一则新闻的状态有三种“撰写中”、“审核中”、“发布中”，普通用户可能只能将新闻的状态由“撰写中”改为“审核中”，而高级用户可以直接将新闻的状态调整为“发布中”。
讨论越来越深入了,very good!
toptomcn提出的问题我想是不是这样理解:
对于一个新闻系统(resouce),它有这样的一些功能点(或者privilege)查看,发布,删除,修改;假设对于删除,有"新闻系统管理者只能删除一月前发布的,而超级管理员可删除所有的"这样的限制,我认为这属于业务逻辑(business logic),而不属于用户权限范围.也就是说权限负责你有没有删除的permission,至于你能删除哪些内容应该根据你userRole or userGroup来决定(当然你给userRole or userGroup分配权限时就应该包含上面两条业务逻辑).
>>对于一个新闻系统(resouce),它有这样的一些功能点(或者privilege)查看,发布,删除,修改;假设对于删除,有"新闻系统管理者只能删除一月前发布的,而超级管理员可删除所有的"这样的限制,
<<我认为可以：
1。“删除一月前发布的”和“删除所有的”作为两个不通的功能点（privilege）；
2。或者干脆把privilege也做成树结构
删除所有----删除一月前发布的
|_删除2月前发布的
|_...
>>我认为这属于业务逻辑(business logic),而不属于用户权限范围.也就是说权限负责你有没有删除的permission,至于你能删除哪些内容应该根据你userRole or userGroup来决定(当然你给userRole or userGroup分配权限时就应该包含上面两条业务逻辑).
<<不大明白最后一句的意思
1.用户，代表一个角色
2.用户组，组可以包含用户，组内用户继承组的权限。
组不能包含组（简化处理，不然会出现组是树状还是网状的问题）
3.资源，可以反向包含自身，即树状结构
每一个资源节点可以与若干指定权限类别相关
可定义是否将其权限应用于子节点
4.权限，包括系统定义权限和用户自定义权限
用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限）
5.用户和用户组直接指定与资源的关系，没有rule。主要考虑权限类型太多了，rule会更多，用户组可以在一定程度上代替rule
新闻
|-发布
|-删除
|-...
"删除"功能不能再拆分了!这样你的功能点会聚增.我们说对于一个像新闻系统这样的resouce,一般地讲具有publish,delete,modify这样的功能,但不会说它有删除一个月,删除两个月等这样的功能;所有的"删除"从功能上讲都是一样的,至于是删除哪些新闻就由用户需求来决定了.如果某用户有删除一月,两月这样的需求,这说明了他的业务规则,在给一个角色或组赋权限时可以这样:
<?xml version="1.0" encoding="UTF-8"?>
<userRole>
<administrator>
<resource>
<news>
<privilege>
<publish permission="true"></publish>
<delete permisssion="true">
<limit>ALL</limit>
</delete>
...
</privilege>
</news>
...
</resource>
</administrator>
...
</userRole>
这里我试着用XML来描述一下,请大家指正!
<pre>
[?xml version="1.0" encoding="UTF-8"?]
[userRole]
[administrator]
[resource]
[news]
[privilege]
[publish permission="true"][/publish]
[delete permisssion="true"]
[limit]ALL[/limit]
[/delete]
...
[/privilege]
[/news]
...
[/resource]
[/administrator]
...
[/userRole]
</pre>
这里我试着用XML来描述一下,请大家指正!
试试从语法的角度来解释权限：
Privilege 如"删除" 是一个抽象的名词，
当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。
还是拿新闻发布来说，发布是一种权限，但是你只说发布
它是毫无意义的。因为你不知道发布可以操作的对象是什么。
只有当发布与新闻结合在一起时，才会产生真正的 Privilege.
这就是我一直在说的 Privilege Instance.
删除可不可以有删除一个月，两个月文章的权限之分？
按照我上面的解释，当然是可以。
讨论到这，可以提一提另一个问题：
正如大家看到的，权限系统根据需求的不同可以延伸生很多不同的版本。
所以我建议先建好一个模型，利用 Java 接口设计的灵活性，可以搭好一个框架，然后，根据不同的需求，提供不同的具体实现
以上是一点拙见，希望指正