根据实例谈谈权限设计

出题如下：
一个系统，对于用户管理模块来讲，不同的管理员分管不同的用户。（譬如部门1的管理员只能管理部门1的用户。。。）权限如何设计？

我的思路如下：（在structs中应用）在action中进行资源设计。将受保护的资源放到xml中，然后利用acl来进行权限的判定，判断资源（假设用户管理为usermanager.do）针对用户是否允许访问，这是粗粒度的设计。然后对于具体的每个用户，就要根据用户的ID来判断部门管理员是否有对他操作的权利了，这一部分要进行细粒度的设计，我目前的想法是把这部分放到usermanager.do的interceprot中，利用aop来进行判断。如果要是和业务逻辑相关的话，就只好放在业务逻辑中了，但是本例应该不存在此问题。

方法2：不用acl，全用aop来做，但是这样的话就要将所有的受保护资源都要加上aop，修改配置文件的时候会不会很麻烦？

针对以上情况，大家还有什么更好的设计，一起讨论一下。

AOP + ACL 的做法不错。
关于ACL。ACL适合文件系统这样的，用户个数不多，变化不大，而Resource Object（文件、目录）的变化很大。
你这里的 url 是属于 Resource Object，是固定的。而用户的数目是不定的。也许RBAC更适合。
如果需要知道RBAC是什么，可用Google, 或在javaeye搜索。

J2SE里面有 JAAS, JSSE等，里面分别由RBAC, ACL的接口和实现，可以参考。

回buaawhl
我看了你在论坛里一篇关于RBAC的文章，对RABC也有所了解，你说论坛系统比较适合采用RBAC模型，根据我对你文章的理解，论坛虽然是以用户为中心，但是我觉得不适合用RBAC，我觉得用ACL比较好，因为论坛的子论坛是可以变化的啊，而论坛主要就是对子论坛进行授权啊，譬如斑竹的等。再如目录树结构的，我觉得用acl都会有较好的效果，反而对于一些栏目比较固定的模块，用RBAC可能会有很好的效果。

以上是我的理解，不知道对不对，请 指教！

ACL 也可以。:-)
这种WEB URL权限管理，网上有很多例子。可以搜一下。

在网上看了一天关于权限方面的设计，太多的名词，感觉有些糊涂了。我现在已经区分不开ACL和RBAC的模式了，麻烦buaawhl给讲讲。

目前我的感觉：
ACL:以资源为主
RBAC:以角色为主

但是实际开发的时候，譬如拿目录树结构来说，譬如就是信息发布系统吧，有很多个栏目，每个栏目又有添加，修改，删除等功能，很明显需要对每个栏目的这些功能进行划分。

所以在实际设计时，应该对每个栏目建立不同的角色，这应该就算是RBAC吧？

然后授权之后在访问的时候利用checkPermission(用户名,栏目名,具体的操作)，具体校验是根据用户名取出其group（如果没有的话可以去掉）,然后分别根据用户名和group找出其关联的Role，再根据Role找出Permission，进行校验。
是这个流程吧？？
怎么我总觉得这里面也包含着ACL呢？栏目明明就可以看做是一个resource，只不过是在所有的判断流程中是用Role去关联而已。
所以现在我感觉RBAC中包含了ACL，这是一个错误的结论吗？

那么真正的ACL和RBAC有究竟是什么呢？

另外，再问个问题，java.secutity包到底是干啥用的？从来没用过：）好象看JAAS用到这个包了，实际我们自己的权限认证和这个包没多大关系。

不用执著于概念。RBAC和ACL的差别不是很大。RBAC多了一个Role。你给ACL加上Role，就和RBAC差不多。
我尽量用相同的table name比较他们的 DB Schema。

RBAC:

(1) user, role, permission, user-role, role-permission 五个表
(2) 这个permission 表里面定义了 operation, resource object两个字段。

ACL
(1) object, permission, object-permission 三个表
(2) 这个permission 表里面定义了 user, operation 两个子段。

--

java.security 以前主要用来检查 代码code 的权限（根据Policy判断这段代码是否可以执行）。
现在加入了Subject （相当于role）, 和认证部分，javax.security.auth.login (user login)，可以用作 RBAC。
说实话，我感觉那套API相当蹩脚。
由于是标准，第三方提供了不少SPI （NT, Linux 验证）。你如果遵守这套标准（提供Adaptor），别人用起来就舒服一点。

具体我没有用过。但是在网上看到过很多这方面的例子。
sourceforge上的 JGuard, JBoard, JProject. 自己可以在sourceforge商用JAAS搜索。
javaeye的另一篇帖子提供的信息。JDJ上一篇文章的中文翻译。
扩展JAAS
http://www.matrix.org.cn/resource/article/638.html

代码本来在JDJ上有下载。这次找了一下，没找到。就把以前下载的放在这里。

到目前为止，还没有发现ACL比RBAC有什么优越的地方。
RBAC带来的最明显的好处就是通过角色继承简化权限的管理。
而ACL个人觉的是比较原始的AC方法。

是的，怪不得我对这两个名词分辨不清，那其实ACL就算是RBAC的一个父集合了，只不过RBAC是在ACL的基础上，又多出了一个角色的概念罢了（大体是这样的）。

对于用户比较固定的而且数量不是很多，而资源很多很动态的情况下，如果要是按角色分配的话，角色会很多，而一个角色起不了太大的作用，而直接针对用户授权，既方便又快捷，这就是ACL。

而如果用户很多，不方便授权的时候，就可以利用RBAC来实现。

恩，非常感谢buaawhl的精彩回答，解决了我在这两个名词语义上的模糊。


不同意你的意见，就象我上面说的那样，如果没必要用太多的角色的时候，就可以利用用户直接和资源关联，在资源里对用户进行控制，以后不想用这个资源的时候，只要在这个资源中把用户去掉就可以了。

角色继承？怎么理解，每次产生一个新的角色？还是？
角色之间是否独立？还是相互包含？

其实ACL和RBAC最重要的区别在于RBAC更符合现实的思考方式，即在拥有某个角色的情况下才拥有相应的权限，而不是某个人就拥有相应的权限，人在社会中都是因为扮演不同的角色获取到不同的权限，而不是说因为你是某某人你就可以拥有这种权限，这是RBAC最大的不同，其实这也是OO思想的重点所在
ACL固然灵活(因为它很好理解)，对于小系统而且权限要求不是很高的情况下是挺好用的，RBAC对于权限系统是真正灵活的设计，但灵活的设计必然带来难度，这个对于大型系统才好用，否则不值得去做，就象unix使用RBAC
总之一句话，应该是根据需求来确定自己到底要选用什么技术来解决，而不应该过分的去追求技术的先进性