ACL和RBAC的讨论

ACL:以资源为主
RBAC:以角色为主

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

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

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

那么真正的ACL和RBAC有究竟是什么呢？
不用执著于概念。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），别人用起来就舒服一点
是的，怪不得我对这两个名词分辨不清，那其实ACL就算是RBAC的一个父集合了，只不过RBAC是在ACL的基础上，又多出了一个角色的概念罢了（大体是这样的）。

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

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