我想理一理思路，看看 ACL 与 RBAC 的区别:
还是以部门新闻来讨论，对于静态授权，在系统设计做需求分析的时候，往往就可以
确定一个系统角色的种类，像新闻系统中，根据需求，可能会有新闻发布者(Publisher)，
新闻审核者(Reviewer)，新闻浏览者(Visitor)，管理员(Manager)以及超级管理员(Administrator)。
在设计的时候我们也已经把这些角色与相应的一些 Operation 绑定在一起。
如：Publisher 拥有 Publish_Operation + Modify_Operation
Reviewer 拥有 Review_Operation + Modify_Operation + Delete_Operation
Visitor 拥有 Visit_Operation,
Manager 拥有 Create_News_System_Instance_Operation +
Modify_News_System_Instance_Operation +
Delete_News_System_Instance_Operation
Administrator 负责 Create_User_Operation+
Delete_User_Operation+
Assign_Permission_Operation+
Deassign_Permission_Operation +
Assign_Role_Operation+
Deassign_Role_Operation
在授权时，往往先为一个用户(USER)，赋予一个角色，如: Manager. 这样，USER 就
拥有了对所有 News_Instance(也就是部门新闻) 操作的权限。
现在假设用户(UserA)访问 Create_News_System_Instance 功能来创建一个新的新闻实例，
叫做 采购部门新闻. 因为我们在设计的时候就确定，该功能只能由 Manager 来访问，
于是，系统中权限的判断部分会首先判断当前用户(UserA)是否 Manager 角色，是的话就允许
访问，否则显示没有授权的错误信息。
所以，对于 Manager 这样的应用:
[1] 在设计的时候，我们就将这样的角色与相应的 Permissions(A list of Subject-Operation pairs)
关联在一起了，这里的 Subject 是所有的新闻实例(News_Instance),Operation
就是 Create,Modify以及 Delete.
[2] 在授权的时候，超级管理员(Administrator)可以利用 Assign_Role_Operation 将用户(User)
与 Manager 这个角色关联起来。这样，User 就拥有了对所有新闻实例的 Create, Modify 以及 Delete
操作的权限。
[3] 在权限判断的时候，RBAC 系统首先判断当前用户是否是设计时确定的角色(这里是Manager),
如果是，就允许用户访问，否则就拒绝访问，并显示错误信息。
对于 Publisher 这样的角色有些不同，Publisher 这个角色只与 Operation 绑定在一起，并没有与
具体的 Subject 相关联，因此，在授权的时候，还需要指定相应的 Subject.
所以，对 Publisher 这样只能事先确定 Operation 的应用来说:
[1] 在设计的时候，我们只能确定该角色能进行哪些操作，而不能确定这些操作实施的对象。
[2] 在授权的时候:
[2.1] 首先将 Publisher 与 Subject 关联,如将 Publisher 与采购部门新闻关联产生:
采购部门新闻_News_Publisher 的角色
[2.2] Administrator 为用户(User)授于 采购部门新闻_News_Publisher 角色。从而 User
拥有了对"采购部门新闻"的发布权限
[3] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation, 系统首先判断
该用户是否 采购部门新闻_News_Publisher?如果是，就允许用户访问，否则就拒绝访问，
并显示错误信息。
这里用到的方法可能是这个样子:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
List publishers = RBAC.findRole(new Permission(采购部门新闻,Publish_Operation));
if(publishers==null) return false;
for(Iterator it = publishers.iterator; it.hasNext();){
Role publisher = (Publisher)it.next();
if(publisher.isAssignedWithUser(User)){
return ture;
}
}
return false;
}
假如说，不采用 RBAC 的做法，考虑一下，使用 ACL，那又会是什么样子呢?
对于 Manager 那样能在设计时就确定 Subject 与 Operation 的角色，我认为没有必要考虑 ACL 了.
对于 Publisher 这样，只能事先确定 Operation 的角色，我们来做个对比.
权限系统要灵活，但是也要简洁，要不然就很可能导至失控。因为嵌套的层次太多，有可能发生不可
预知的情况. 有一天管理员可能会莫明的发现，怎么这个人会有这个权限的?
所以，我认为在 RBAC 里不支持 Role 的层级关系为妙。
好了，现在来看看 ACL 对 Publisher 应用
这里指的 ACL 是直接将 User 或 Group 与 Subject 关联的做法。
User 与 Subject 是多对多的情况，
Group 与 Subject 也是多对多的情况，
同样的，User 与 Group 也是多对多的情况。
现在，还是以采购部门新闻为例:
[1] 在授权的时候，可以有以下操作:
[1.1] 将 User 与 Subject 关联在一起,但是要指定相应的 Operation.
如: assignPermission(采购部门新闻,Publish_Operation,User)
[1.2] 将 Group 与 Subject 关联在一起:
如: assignPermission(采购部门新闻,Publish_Operation,Group)
[1.3] 将 User 与 Group 关联
如:
assignUserGroup(User,Group)
[2] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation，系统做如下检查:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
boolean hasPermission = false;
// users include:
// 1. Permission direct assigned Users
// 2. The user assigned with the groups that assigned with permission
List users = getAssignedUsers(new Permission(采购部门新闻,Publish_Operation));
hasPermission=users.contains(User)?true:false;
}