好文！

我们现在做的项目，开发考虑权限部分很多，很充分；
1）系统权限
2）数据项权限
3）业务对象相关权限
但最后觉得过于复杂，可操作性
就差了；所以一个实用安全的
权限系统不是仅仅考虑这些
技术层面就够的！

有关基于角色的权限管理，有个问题想请教各位。在一个项目中，权限有操作权限和数据权限，据个例子：比如说对某大公司的财务报表进行管理，对报表有三种操作：创建、删除和查看。公司很大，分不同的地域
地区A1
地区A--地区A2
总部--
地区B--地区B1
地区B2
假如员工emp1和emp2，emp1只有地区A1报表的查看权，emp2有地区A1报表的所有权限，如果针对上述权限的话，是不是要建立两个role，一个是对A1报表的查看权role1，一个是对A1报表的所有权限role2，然后把两个权限分别赋予emp1和emp2，要是这样的话，岂不是要定义很多很多角色才能实现各种功能！不知道我的理解对不对，请各位指教，谢谢！

对不起，上面的图没有显示出层次，应该是：
-------------地区A1
------地区A--地区A2
总部--
------地区B--地区B1
-------------地区B2

不适宜这样做的，这样就把业务和功能权限纠缠在一起了，达不到通用的效果。建议数据权限做在具体的业务中。

请各位大侠指教，不知道我的理解对不对，针对于上面的报表操作，我是这样设计的：
定义一个资源基类：Resource，派生出报表类：formRes，报表类里定义一些属性，如：地区、创建时间、所属人等。
定义一个权限基类：Permission，派生出报表权限类，定义方法：删除报表类delFormPer，创建报表类creFormPer和查看报表类seaFormPer，每个方法有单独的id号。
定义一个角色基类：Role，派生操作form的角色类：formRole，在派生出formAdmin角色，包含所有操作form的权限；formUser角色，只包含查看form的权限。每个角色都有唯一的id。
在应用时，分别对相应的用户赋予相应的角色。
比如在定义权限类中的方法时，可以定义多种方法来细化，例如在察看报表方法时，可以定义seeFormPer(formRes district)，输入form的所属地区，就可以查看该地区的报表。不过这样的话定义的权限会很多。
不知道我这样的设计可不可行，敬请各位指教，谢谢

地区的问题应该放在RBAC约束模型（或称约束条件）中去考虑，约束条件是与业务逻辑紧密相关的，并与RBAC是平行的、互不相干的、不可比较的。

什么是约束模型，具体怎么定义和实现，能否祥述，非常感谢！

约束条件一般与业务逻辑相关，RBAC中没有明确的形式定义，但一般会考虑前提约束、数量约束、时间约束、角色冲突、特权递减等。

大家好，看了这篇文章和讨论很长见识，难得有这样一个高水平的论坛。这里还有个问题不太清楚，想请教大家。
权限设计基本上应该包括组织机构，ACL，资源这三个模块，也就是who do what。

那么具体的权限分配放在哪一个模块比较合理？
如果放在组织机构上，就是user或userGroup或role可以得到一个authority，该authority判断该资源是否包含在内。
如果放在资源上，就是资源可以得到一个permission，资源判断该permission是否包括该用户。
如果放在acl上，acl可以得到一个operation，资源访问该operation，判断该用户是否包含在内。

三种做法似乎都可以满足需求。并存似乎也可以。那么究竟那种比较合理易用呢？

如果说的有错误，还请大家指正

so good!!

to hyzou

在RBAC基于角色的权限系统，那么权限分配应该放在ACL这里，在ACL这里只有角色和权限两种概念，没有其它概念，这样以角色为分界线，将权限和用户或用户组分开是RBAC的最大特点。

RBAC认为给group组分配权限是一种高度欺骗。因为用户权限系统复杂，所以引入角色概念分开它们，千万别再将它们搞在一起。

很不错的帖子，但是好像对于更加复杂的权限控制没有考虑到，实际上，权限系统很复杂的，不同的应用所要求的权限是不一样的。

例如，经常遇到的情况，在一个系统中
部门和公司主管可以看到自己部门或者公司下面所有的人的情况
普通员工可以看到自己的信息
HR可以看到自己公司所有人的情况
主管部门中，部长可以看到本部门管辖的所有部门的情况，但是一般成员不能管理部长的信息
可能会出现一个公司的HR部门需要管理其它公司的人事信息，但是不能管理薪资信息

这里复杂的情况在于如何确定权限管理的层次关系，或者说汇报关系（report to），被汇报者可以管理汇报者的信息，直接或者间接，这一般都是通过企业的行政组织关系来确定的，比如公司管理部门，部门管理小组，小组管理成员等等。

进一步，有的大型企业会引入矩阵式管理，这就更加增加了系统的复杂性，例如，一个北京地区的汽水销售经理可能既要管理北京地区的销售部门的工作，又要管理全国的汽水销售，这本身就是不同的report to关系

to banq:

thank you :)

to numiddle:

你说的很有道理，这就说明权限和实际的工作岗位是密不可分的，这个在工作流中体现更为明确。

所以我的观点，user，group，role一个都不能缺。group就是现实中的岗位，是一个树状结构，而role是为赋给权限方便而单独提出的组，是一个扁平结构。这三者都属于纯粹的组织机构，和权限毫无关系。

组织机构的目的就是能够方便的分清楚人与人之间的关系。方便而易用的取到用某种关系联系到的人。

而权限的赋予完全移到acl中，工作流中的权限还会随时间和空间而变化，这些在设计的时候都应该考虑到