一般来讲:role与group相似于包含一组用户,role与group有以下几点不同:
1、role有继承关系,role间是有层次关系的。
2、rbac中role支持约束,特别是权责分离。

to colin_qiu:

role的继承关系是这个吧:每个role会赋予不同的权限,而子节点上的role除直接赋予的权限之外,还自动获得父节点的权限。

这个我看了一些资料,认为这种设计并不合理。因为一个高级用户未必需要那么多低级权限。这并不是一个充分条件。

另外你说的那个权责分离能说的详细一些吗?

看了这篇文章后,受益匪浅,真是感谢。最近看了一些JAAS方面的资料。有一些疑问,请高手多多指点:JAAS利用策略文件来管理权限,实现授权,利用命令行的方式很容易指定策略文件:如利用-Djava.security.policy来指定标准策略文件,利用-Djava.security.auth.policy,指定JAAS策略文件,利用-Djava.security.auth.login.config指定登录配置文件。但是在开发web应用时,如何使用文章中提到的安全模式呢,JAAS应该具体在web应用的哪个层次应用更好一点,配置文件如何指定?说白了,就是各位高手能否给出一个较具体的J2EE实施方面的例子。另外,文章中给出的安全模式是一个较为通用的模式,稳中谈到的角色、用户等也是较为通用的概念,具体在j2ee中尤其是使用JAAS时,这些概念应该如何实现?请高手指教,谢谢!!!

sourceforge上有个pow2acl项目,很不错的:)

作者所说的RBAC和自主型访问控制方法(第1种)有什么区别吗?

我这两天在做会员系统的设计,我将权限部分从会员系统中独立出来,成为一个独立的系统。会员系统完成用户管理和身份认证,权限系统完成权授权管理和权限验证。

在我的权限系统中主要有这几个类或者接口:SecureFactory,SecureManager,SecureObject,SecureModule和Privilege。

SecureFactory:工厂类,负责构造SecureManager的实例。之所以这样做是想让SecureManager支持本地和远程两种调用方式,不同的调用方式用不同的SecureManager实现支持,比如EJBSecureManager。

SecureManager:权限系统对外的统一接口,提供grant,revoke,和权限查询的方法,采用接口设计。

SecureObject:授权的对象或者可进行权限判断的对象,采用接口设计。User,Group,Role或者组织机构,文件,URL资源等都是SecureObject。SecureManager在进行权限县官操作的时候只接受SecureObject对象。

SecureModule:权限判断逻辑的抽象,采用接口设计,提供gant和权限查询的方法.如上所述,权限系统中可以进行权限验证或者可授权的对象有很多种,不同的授权对象进行权限判断的时候都有自己的逻辑,因此要让权限系统尽可能满足这些要求,有足够的扩展性,我将这部分逻辑抽象出来。

Privilege:权限

这些类是怎样协作的呢?以一个基于角色认证的权限判断为例子,我是这样做的:
1。开发一个RoleSecureObject,让这个RoleScureObject可以接受角色对象

2。开发一个RoleSecureModule,完成具体的权限判断和权限查询的方法

3。在xml配置文件中进行配置。
申明RoleSecureObject,并设置这个SecureObject的module为RoleSecureModule

4。具体的判断代码:

SecureManager sm = SecureManager.getInstance();
sm.grant(new RoleSecureObject("Administrator"),"usermanager/add");

sm.hasPrivilege(new RoleSecureObject("Administrator"),"usermanager/add");
//或者
sm.hasPrivilege(new UserSecureObject("dev"),"usermanager/add");


如果是要对其他资源进行授权和权限判断只需要开发新的SecureObject和SecureModule并添加在xml配置文件中就行了。

很好的文章,受益非浅压~~~~~~~
大家都在如何建立一个权限系统上,提出很多很好的建议和实现思路方法,我倒想到了如何让以后我们开发的系统可以公用这个权限系统的问题。
假设我们建立了一个权限管理系统,现在我们要开发一个网站,把权限这一块作为网站内部一个子系统,关键问题在于我们开发的网站通过什么样的接口从权限系统获取什么样的权限信息,从而完成实际意义上的权限控制。权限系统做得再好,如果没办法给其他系统公用,那它只是一个完全孤立的东西,用处不大。
我的想法是:权限系统除了管理好权限的定义分配等问题,最主要的是提供权限查询的接口,其他系统通过(User,Resource,Operator)三个参数查询此人(user)是否具有对Resource的Operater权限,或者通过(user,Resource)返回Operater的列表,具体的权限控制,有程序员自己控制,这部分控制就是上面所说的“细粒度”的属于业务逻辑的控制了

我发现在设计权限系统的时候有三个地方是要重点考虑的。

第一,是权限判断逻辑的复杂多变性。代文龙文中所说的粗细粒度的权限判断都是权限判断逻辑,而他要把细粒度的权限判断逻辑放入业务系统中处理也是因为其判断逻辑的复杂多变性。权限系统不能包办所有的事,但是要能够有很好的灵活性和扩展能力,让开发者写少量的代码就能够尽量多的支持这种变化。可以考虑采取插件的设计方式设计权限判断逻辑。

第二,是资源的多样性。这体现在两方面,一个是资源多种多样,比如文档,新闻,功能,商品,目录等等,其存储结构以及管理方式几乎都不一样,而且资源是在应用系统中定义和管理的,权限系统只能对资源进行全线设置。另一个是权限系统中可能要同时涉及多种资源的权限设置和判断。权限系统在着反面要有足够的灵活性和扩展能力。

第三,是可授权的对象。这里的可授权的对象一般就是用户了,但是业务系统通常有更多的要求,比如要求对用户组、组织机构授权。权限系统在设计的时候应该考虑这一点。

我对权限系统的看法:
权限系统的核心正如jackyz所描述的 判断“who 对 what(which) 进行 how 的操作”的逻辑表达式是否为真。是一个三元组。

权限三元组:user+Resource+Privilege

who:user
what:Resource
how:Privilege

user包括group和user。group是user的一个集合,group与user是多对多的关系。group与group当然之间也是多对多的关系。实现时可考虑将group与user等同,没有子的group即为user。不过这样较为抽象,不为一般用户所接受,所以一般分开实现。此处不应将组织关系与group混为一谈。用户与用户组组成的应该是一个图,而不应是一棵树。在具体应用中可考虑将其关系变成一个树的关系。

privilege包括privilege和role.两者之间的关系如同user和group之间的关系。在此不作太多讨论。有些朋友把role与group等同。我觉得在概念上是不对的。group是user的集合,而role是privilege的集合。而在具体实现上为了降低系统的复杂性,可以将group与role合并实现。

resource包括resource和package。package是resource的集合,关系同user和group之间的关系。在一般系统中可不实现package。在具体实现中可将resource和package等同实现,没有子的package即为resource。

上述为权限系统的core。下面是处理多种类型资源的权限系统扩展。他只是为应用系统提供服务的。是一种约束条件。不出现在权限三元组之中。

为了考虑到不同资源类型的resource拥有不同的Privilege。应引入resource type和Operator.

resource type 是resource的一个type信息。当然Privilege也属于resource。每个resource有一个resource type属性。resource type与resource是一对多的关系。resource type与resource type之间是多对多关系。当然为了实现简便可以实现为一对多的关系。

Operator表示resource type与privilege的关系。只是一种限定条件。即表示在某类资源上有某种权限或权限集合。是为应用系统服务的,并不是权限系统的核心。


再往外层走可能还包括某类资源(resource type)限定在某些user(用户或用户组)内。但它也只是权限系统的一些附加服务而已。

没有进行校正,希望批评指正 zjh_yan@163.com

这篇文章应该还有一张图的?能发上来看一下么?

用户属于组,组具有一些角色的组合,角色具有某个集合的权限;

这样的用户权限分配可能有些问题,如果要给某个用户增加一个劝降,
就只能赋予某个角色权限,这样组内的所有人都有这个权限,难道只能
新增角色或者组?

建议数据权限做在具体的业务中

> 建议数据权限做在具体的业务中

这是说写在具体的程序里?硬编码?
如果地区会变,人员也会变.那该怎么办呢?不知道那些大公司的软件,权限控制怎么用的?

另外,楼主的文章我反复看了好几遍,但觉得其中有些不懂.(有些混乱,不好意思,可能是我还没理解吧,我打算打印出来连续看三天,呵呵)
比如group和role没有关系.那user属于多个group又有什么作用呢?反正user已经有多个role了.
是不是应该:
User
/ | \
group1 .. group2 ->
| \ |----|
role1 ...
| \
privilege1 ..
|
subject+operator(subject可以有子subject时, 我难道每次用时去遍历?)

真是太节约空间了.把我左右的空格都过滤掉了.
强烈建议斑竹允许使用空格啊.
那个图片我白打了.重来一次:

谁能够提供些具体的关于企业门户的权限设计的资料呢?

麻烦啦,给点思路,现在乱得很:(