基于目录结构认证的问题

　　目录结构以Ｔｒｅｅ形式展现，按照ＲＢＡＣ的规范，我把目录当做一种资源(resource)，然后以privilege=resource+operation来定义权限，operation包括view,edit,check in/out等，
定义一个权限的大概流程是：在目录树上选择某一目录节点，然后选择一种操作类型，由此定义一个对该节点的权限privileg1。
按此方式授权：privilege1->role1->group1,因此属于组group1的用户就拥有对该节点的操作权限privilege1,节点权限具有继承特点。
　　如果按此方式定义权限的话，那么随者目录结构树的增长，权限会越来越多。
　　另外一种方式就是先定义好操作权限，比如view privilege,edit privilege,check in privilege,check out privilege，把ｒｏｌｅ和ｐｒｉｖｉｌｅｇｅ的概念等同起来，即预先定义好基本的固定角色view role,edit role,check in role,check out role。
目录结构的安全策略是：树节点授权给某个角色role1（edit role），于是拥有该角色的ｇｒｏｕｐ就有权限对该节点以及子节点进行edit的权限，如果再把该节点授权给role2(check in role),那么同时拥有role1和role2的ｇｒｏｕｐ就能对该节点及子节点进行edit和check in的权限。
此方式对树节点是进行粗粒度授权，而且不符合ＲＢＡＣ中privilege=resource+operation的规范。
不知大家对目录结构认证有什么心得和建议？

对楼主的话题很感兴趣，却又不知道如何回答才好。楼主的描述中包含了太多具体扩展和具体实现的东西。似乎在描述 CVS 的局部功能的权限控制的个人实现。

http://csrc.nist.gov/rbac/
这是 Role Based Access Control 的一个比较权威的网站。
（其中的Case Study 部分包括一个CVS Server RBAC的概要描述，但不够具体。有兴趣可以看看，但具体设计方面的参考价值不大）

你说的privilege是什么概念？是指 Permission吗？
RBAC 的核心部件只有 3 个， user <-> role <-> permission
其中的Permission = Operations + Object.

你引入了group, user <-> group 之间还有关系， group <-> role 又有关系。group 应该属于你对user 部件的扩展了。
这里要提醒一下，你也许受了 user <-> group <-> permission模型的影响。
这两个模型中的group 和 role的作用重合的。很多情况下，这两个模型也是相同的。但是，并不完全相同。比如，Role只见可以具有(Hierarchy)继承关系。而Group大多数情况下，是flat结构。
user <-> role <-> permission 是 彻底的RABC模型。
user <-> group <-> permission 可以映射为 上述的RABC模型。

Java Security 架构基本遵循着 RBAC Model. 定义了Principal, Subject, Permission等类。
我借用其中的 java.io.FilePermission 来解释一下 Permission 这个部件。（因为FilePermission也是对目录结构的权限定义）
Permission = Operations + Object
这里的Operations的个数是限定的，就是你说的 view,edit, check in, chek out.
而这个Object 正如你理解，可以代表一组Resource Object. 比如，一个包含子目录的目录定义。
FilePermission就是这样的。
比如， a = new FilePermission(“root/mydir”, “read”);
b = new FilePermission(“root/mydir/child”, “read”);
那么, a.implies(b) == true, 就是说，当一个role 具有 a 权限(permission)的时候，自然就具有了b权限。
如果 b = new FilePermission(“root/mydir/child”, “read, write”);
或者b = new FilePermission(“root/otherdir/child”, “read”);
那么a.implies(b) == false。


你的说法，相当于把 operation 和 role等同起来。不推荐这种做法。



这种做法是对的。但你这里可能和 ACL (Access Control List) 权限模型弄混了。
RBAC模型中，这两个映射关系应该是分开的。
Permission <-> Role
Role <-> user

反映到DB Schema 就是这样的两个table.
Create table RolePermission {
Role Id,
Operations,
File Path,
}
Create RoleUser table{
Role Id,
Operation,
File Path,
}

操作起来，你要先把 Permission (Operations, File Path) 和 Role 联合起来。
比如，
Role ID | Operations | File Path
-----------------------------------------------
Adminstrator | all | root
Developer | view,check in | root/mydir

然后再把 Role 和 Group (User) 联合起来
Role ID | User ID
----------------------------------------------
Developer | buaawhl
Developer | chikaiwang
Adminstrator | chikaiwang

请教一个问题

对于rbac权限模型
user <->role<->Permission
我的理解：对于用户（管理员）来说，新建一个角色：其实就是R＝R1+R2，我想不可能叫用户直接建立R <->Permission，而只有开发人员去建立R <->Permission
那么在交付给客户的时候开发人员应该已经初始化好一堆基本的roles。
是这样吗？
如果是，那么开发人初始基本的roles的时候：
对于一个object：tree，相关的Operations：x1,x2,x3
来建立role<->Permission关系：
r1<->{tree,[x1]},r2<->{tree,[x2]},r3<->{tree,[x3]},r4<->{tree,[x1,x2]}......
这样我觉得如何初始系统的基本roles，是很头疼的事，还有角色名称的“命名”也叫人难受。
你有什么好的方法吗？

感谢buaawhl的答复。


是的，更专业的叫法应该是Permission。
可能我上面没描述清楚，我就是按下面方式模型定义RBAC的:
Permission = Resource+Operation
Permission<->Role
Role<->Group
User<->Group
User<->Role
但是为了系统简单化，去掉User<->Role这一对应关系。

这种做法比较直观和符合RBAC思想，但是会出现随着目录结构树的增长，系统的权限越来越多的问题。

我上面说的第二种方法就是这样的，初始化好一堆基本的roles。

开发人初始基本的roles，就是初始化这几种：view role,edit role,check in/out role,在这里没有了Operations的概念，Role模糊化为Permission。
然后针对某一Tree节点授权时，可以选择不同的role。这种做法比较简单，但是不直观和规范。

用户直接建立R <->Permission 是很常见的功能。
"Assign Permissions to Role, "
"Assign Roles to User "
这也是两种 Permission. Object = user, role; Operations = assign.
比如，NT系统管理员 可以定义组、域和用户的关系。
论坛管理员也有类似的权限。

初始系统的基本roles，这个功能应该由系统提供。具体来做，要系统管理员来做。

另外，楼主关心的问题，给 目录对象 设置权限。
其实是一种 Object Centric 的思路, 这个时候，ACL 权限模型更适合。
比如，Windows系统下，我们共享目录的时候，先选择一个目录，然后选择 read, write 等，然后选择哪些用户可以访问。这是典型的ACL模型。

而RBAC本身是一种 User Centric 模型。
楼主也许想把 这两种模型结合起来。

这里有一篇文章。
Role-Based Access Control Using Windows Server 2003 Authorization Manager

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetserv/html/AzManRoles.asp

讲解怎么在 Windows 2003 这样的 Object-Centric ACL权限模型上，建立 User-Centric RBAC 权限模型。
这是一种映射工作。
Java Security 也有这样的映射。比如，映射到NT, Unix, LDAP, DB, File等。
Turbine 是一个很好的 RBAC Web Framework, 也有类似的映射。

如何解释？

从你的描述来看，你管理的中心不是user, 而是目录、文件系统等Object。
文件系统一般都采用 ACL 权限模型。(ACL is Object Centric Security Model)
用户为中心的系统，比如论坛等，一般采用RBAC 权限模型。(RBAC is User Centric Security Model)

文件系统中，Object 的数量很多，而且经常变化，而用户不会很多，所以重在Object 管理。
论坛系统中，Object 的数量一般固定（category, forum的个数），而user数量很多，而且经常变化，所以重在user 管理。