IDC资讯中心
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
最近，头儿也要我们做一个权限管理方面的通过系统，真是无从下手!
