对权限控制又很深入的讨论(2)

Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月24日 16:24:18 回复

发表人: littlebird 发表文章: 1 / 注册时间: 2003-10
看了这么多关于权限方面的讨论真是受益匪浅。
这里说说我的想法：
我认为对于多数企业应用项目，相对而言都不是很大的项目，权限管理部分是不是可以简化成：user *-->1 role 1-->* operate
用户可能有很多组织上的层次关系，但在这里可以将它压平，不论什么层次都直接和角色相关，而且只有一个角色
权限也可能有很多层次关系（比如新闻包括A、B或C部门的），这里也把它展开，让角色直接最底层的权限相关（如A部门新闻的修改权限）
根据用户获得它的角色，再根据角色获得它拥有权限的集合。

而group是用户的集合，把它加上会变得相当复杂；当然还可以有权限集合的概念也加入，那就更复杂了。



Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月25日 11:07:20 回复

发表人: iceant 发表文章: 413 / 注册时间: 2002-10
我想理一理思路，看看 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;
}

Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月26日 22:32:43 回复

发表人: GreateWei 发表文章: 3 / 来　　自: 宁波 / 注册时间: 2003-07
曾看过ofbiz关于权限设计的相关资料，感觉ofbiz在实现方面有很大的通用性。看过之后，总觉得自己理解的不够透彻，希望大家能详细的讲解一下，谢谢。


发表人: SUPERMY 发表文章: 21 / 注册时间: 2002-10
可以试一试tiles,应该很简单的。用户权限必须在配置文件中写死。



Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月29日 23:26:09 回复

发表人: ninsky 发表文章: 20 / 注册时间: 2003-10
> 可以试一试tiles,应该很简单的。用户权限必须在配置文件中
> 此馈?

呵呵，你说的跟上面讨论的可不是一个概念噢，这些权限是无论如何不能写死的。

没想到几天没来，这个帖子居然让banq提到首页了，乐

感谢各位的指点，我已经将这套系统的大概框架画出来了（具体实现还得等一阵^_^），首先感谢iceant，他的回复很大地扩展了我的思路，我在其它相关帖子中发现了iceant的大量发言，看来iceant是作新闻系统的啊，很多例子中举到了：）

不过，上述的讨论并不能完全套用的我的这个系统中，不知各位看明白我的提问了吗（没看明白？看来我还得好好进修一下语文-_-），在我的系统中不光有功能模块的划分（或说是功能点，显得更细），这方面的权限管理相对比较简单，不管怎样，只需将权限控制到功能点即可，也可以使用角色、组等方便配置。

而在我的这个系统中，有一个很重要的要求就是，信息权限的管理，也就是说权限要划分到某个功能点下的某条具体的信息上去，也就是说，一条信息刚录入到系统中，管理员要对其进行权限控制，那些人或那些组织或那些自定义组成员可以看到该信息，并分别可对该信息拥有什么样的权限（增删改等），当然，绝大多数用户只能拥有浏览的权限，但是在浏览权限方面又有控制，那些用户（或组织、或自定义组）可以看到哪些字段内容是不一样的，这就比较复杂了。

我后来的解决思路是：
对模块（或曰功能点）划分角色，同时对角色赋一些初始权限，这个初始权限主要是针对管理员的，也就是说初始对管理员赋所有权限，一个用户只拥有一个角色。
为了便于信息权限的控制，使用了自定义组的方式，将那些具有相同信息操作权限的人员划分到一个组中。将信息权限（包括字段权限控制）单独进行控制，也就是说除了管理员的初始权限外，这部分的权限控制不再与角色发生关系，而是由管理员对每条记录（当然可以批量操作）指定权限，权限控制到个人、组织和自定义组，在同时也将字段权限进行划分，按照一定的字符规则存储到数据库中去。
不过这样做之后，所谓通用性嘛，就不考虑了



Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年11月01日 10:02:15 回复

发表人: agilejava 发表文章: 14 / 注册时间: 2003-11
最近，头儿也要我们做一个权限管理方面的通过系统，真是无从下手!