1、role有继承关系，role间是有层次关系的。
2、rbac中role支持约束，特别是权责分离。
1、role有继承关系，role间是有层次关系的。
2、rbac中role支持约束，特别是权责分离。
role的继承关系是这个吧：每个role会赋予不同的权限，而子节点上的role除直接赋予的权限之外，还自动获得父节点的权限。
这个我看了一些资料，认为这种设计并不合理。因为一个高级用户未必需要那么多低级权限。这并不是一个充分条件。
另外你说的那个权责分离能说的详细一些吗？
在我的权限系统中主要有这几个类或者接口：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时, 我难道每次用时去遍历?)
强烈建议斑竹允许使用空格啊.
那个图片我白打了.重来一次:
麻烦啦，给点思路，现在乱得很：（