续：关于权限系统的设计

看了上面各位大虾的发言，很受启发，自己的项目也遇到过权限问题，故有点想法，拿出来大家看看。

从我自己的经验来看，一般应用系统的用户都是有清晰的上下级关系的。比如会计的领导是财务主管，财务主管的领导是主管财务的副经理，副经理的领导是经理，等等。许多活动都会使用到这种上下级的关系，比如，财务主管只能看到他手下的会计的工作报告，而不能看到其他人的。这种权限控制的应用很普遍，就不再举例了。因此我认为，user不是相互平行，相互独立的，而是有上下级关系的。

但是，让user之间有上下级关系是不合逻辑的。因为某个人不是天生就是其他人的领导，而是因为他们职位的不同，是职位之间有级次而不是人之间有级次（我们要提倡人人平等，呵呵）。那就引入positon吧，让user之间是平等的（本来就是:)），position之间有上下级关系。一个user可以对应多个position，因为有身兼多职的情况（这才是引入position的真正原因）。

那这种user-position不是和user-group一样了？不一样！
第一，position之间有明确的、有意义的上下级关系，position有实际含义，而group对此要求不严格（这也是group的长处和特色）；
第二，position之间的权限是自下而上传递的，下级的权限上级自动拥有，而不是相反；
第三，我觉得两者的设计思想不同，我的实现是基于关系数据库的，position之间的关系用层次码实现，而jackyz是oo的思想。互有优劣吧，不过我觉得这儿的oo有点勉强。

总结一下：有三个实体
1、User。没什么说的
2、Position。有上下级关系，一个position只能有一个父position。user-position之间是多对多。可以一人身兼多职。
3、Operate。

至于group和role，我觉得只是一种辅助，不是必要的。如果系统的position很多，逐个授权违背了“简单，方便”的目的(jackyz语)，那就引入group，将权限相同的position组成一个group进行集中授权。role也一样，是某一类Operate的集合，是为了简化针对多个Operate的操作。

不好意思，发重了。请板桥大哥删掉一个。

另：论坛怎么没有删除修改功能阿？

对啊你的position就是role(角色)的意思

ZWANGLI 讲的不错，ROLE 与ROLE 是COMPOSITION/AGREGATION的关系，GROUP与GROUP 在OPERATION(PRIVILAGE)上是INHERITANCE的关系，复杂系统ROLE 和GROUP会同时用
我今天到不是来谈设计的，大家已讨论的够透澈了，我是想提个也许不切实际的建议
在很多ERP系统中，权限控制本身就是一个重要的业务，虽然这不是那么OBVIOUS，也不象其它业务那样相对独立，但也不外乎几种常用模式。各位有志者何不凑一下，搞个PLUGABLE 的ACL系统出来。
2 YEARS AGO I DID SOME RESEARCH AS i WAS PLANNING TO BUILD A ERP APPLICATION FOR A IMPORT/EXPORT MANAGEMENT COMPANY IN BEIJING，THERE WERE FEW PRODUCTS AVAILABLE， BUT THEY WERE QUITE EXPENSIVE。
另外，这类软件国情性很重要。
最近没涉足此领域，井底之言务见笑。

先祝各位元旦快乐。
不好意思，最近在瞎忙，几天没上来，已经欠下了各位不少回复。现努力作答，并附上我考虑的思路，给大家参考：

to compl: 谢谢关注，你的担心是不无道理的，不过，看来或许我们之间在理解上还是略有不同。

“……当一个系统的规模已经非常庞大时，即便加上组的继承机制也会显得力不从心。如果一个用户在一个项目里是项目经理，有统筹规划的权利，而同时又是另一个项目的Supervisor，只有监控的权利，而这两个项目有没有什么关系，由两组不同的人来完成，这个情况下……”

这个情况下，在现有的架构中的 User-Group 关系是多对多的，可以简单地给这个 User 赋予两个 Group 的关联，即该 User 同时是两个 Group 的成员。比如，UserA 是 Project A Manager Group 的成员，同时又是 Project B Supervisor Group 的成员。
系统结构中：


     *    *        *    *
User ------  Group ------ Operate
            *|   |1
             +---+
注：
* 表示多重对应
1 表示单个对应

Group 实际上提供 User 和 Operate 之间的“间接关联”。

“另外我觉得不利用ACL，不能动态解析对象与权限的宏表达的权限系统，始终不会非常灵活和强大。”

如果我没有理解错的话 ACL 即 Access Control List ，系统中的 Operate 就是 ACL 的 Item ，而根据规则，一个用户所取得的所有 Operate 的 List 就是该用户的 ACL 了，与 java.security.acl 不同的是这个 ACL 是在 Bussiness Method 级别上并用数据库实现的，或许我们也可以考虑将它以 Java ACL 的配置文件方式来实现。但，对于商业应用，或许并不足够容易配置。至于它的应用，我觉得 Benq 的“动态 Proxy 方案”是一个非常好的实现方式。当然，如果我们对于这里 ACL 的理解有不同的话，那又另当别论了。

“如果对应权限控制的业务逻辑还是需要通过编码来实现的话，那这个系统的价值也会大打折扣了。”

完全配置的，无需编码的，对应权限控制的业务逻辑系统？呵呵，恕我愚昧，还没见过，但或许可以作为我们努力的方向吧。

to zwangli: 谢谢你贡献出自己的想法，你提出的关于“级别”的问题我也正在考虑，我是这么想的。

据我所知 Group 的一种“标准用法”就是如你所说，用来表述“组织结构”的，级别是这里非常重要的一个概念。你提到的 Position-User 应该说极其类似于 Group-User 关系，如果仅拿 Groups 的“一棵树”来看(严格要求父Group)，两者基本上是相同的。具体权限的向上汇合还是向下继承，这可以认为是一个划分角度的不同(实现上也是可以调整的)。最大的区别可能在于 Group 可能会存在“多棵树”，而 Position 肯定只有一棵，可否认为 Position 所表达的关系是这多棵树中的一个呢？也就是说，Position 是 Group 的一种“维度”，Position 之外还存在其他的维度，比方不同的业务处理流程带来的权限划分维度，一棵树对应一个维度，一棵树的权限由不同的人来维护(比方，人事部门维护“公司组织结构”这个系列的 Groups ，编辑部门维护“频道管理权限”这个系列的 Groups ，让权限的分配也能“分而治之”？)。关于维度的想法，我也没有考虑成熟，但我觉得，这可能是能够表述 Position 概念的。

我同意你关于 Group 和 Role 只是一种辅助的说法。但我认为，如果一个功能，能用一个概念来实现，那就尽量不用两个概念来实现。如果 Group 和 Role 在某些情况下都能达成某个目的，而且效果相同。那就有必要精简。当然，我的想法或许过于理想化。一家之言，仅供参考，具体应用，还是要以具体项目实际为准。

to Jevang: 谢谢关注，你的提议很好，等忙完了手头的工作，我会认真考虑设计一个这样的系统的可行性。

Role Based Access Control:

http://csrc.nist.gov/rbac/

在网上找了找资料，发现有这么个东东，大家可以借鉴一下。

以下是我的一点愚见：

我觉得Role和Group如果不分层次的话，其实就是两个词而已，只是语义概念上的差别，如果分层的话，他们也可能是杂合的，例如：
一个公司可能有负责不同区域市场的开发组，每个组下面又有项目管理，系统分析，程序员；（组包含角色）
也可以这么分，项目管理，系统分析，程序员，下面分成若干组，每级，每组分工明细，资料互设权限（角色包含组）

看公司的管理模式，和实际需求了！

haha215A06nv4T7.vsd

主要是由于讨厌电脑辐射的原因和个人能力的问题,好几天都没有把大家的发言看完.
自己已经被这东西困扰好久了.
先后的两个项目都觉得部分没有处理好.
这是我的解决办法:

其实你们的讨论是有关分布式系统的输权管理的问题。对此已有了公认的方法：
基于角色的访问控制系统。有兴趣的可查：RBAC(WWW.GOOGLE.COM)

本人对基于角色的访问控制系统有较深的了解，想要资料的可想我要：xn_jin@163.net

对不起,我本来是不想说的.对于在企业环境中的访问控制方法,一般有三种:
1>自主型访问控制方法.目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs).这种方法以前还可以.但就目前而言,对于较大的企业而言,其不足就明显了.
2>强制型访问控制方法.用于多层次安全级别的军事应用.
3>基于角色的访问控制方法.是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

我目前的研究方向是此方面，并且做过一个大型公安系统的统一资源访问控制系统的开发工作，结果也如上述的一样，对家使用后也非常满意。

我以前在此发过一帖，说我有此方面的有关资料，并留下EMAIL。结果有不少的朋友来信，我也回了一些，但最近又收到不少。故我上传于此。对不起，上传空间有限制。xn_jinq8M522070a.pdf

几点解释：
1、细粒度控制应该在底层解决
Resource在实例化的时候，必然指定Owner和Group；
Privilege在对Resource进行操作时也必然会确定约束类型：究竟是OwnerOK还是GroupOK还是AllOK，类似于UNIX文件系统的权限机制。
2、Group应和Role严格分离
user和Group是多对多的关系，Group只用于对用户分类，不包含任何Role的意义；
Role只授予user，而不是group。如果用户需要还没有的多种Privilege的组合，必须新增ROle，
3、Privilege必须能够访问Resource，同时带user参数，这样权限控制就完备了。

以上是我想到的粗粒度和细粒度一体化的权限模型，欢迎各位一同讨论。

看了诸位大侠的文章，很受启发，但感觉比较复杂。下面是我个人考虑一种模型：

以上是我想到的粗粒度和细粒度一体化的权限模型，欢迎各位一同讨论。

关于权限系统，我以前做过一个系统的权限管理模块。我现在公司的产品也有权限管理部分的内容。这两个系统是完全不同领域的，其中有很多相似的可以借鉴的东西。我做一些简单的补充：（前面的贴子没有细看，唐突之处还请谅解！由于画图不方便，只描述，有兴趣者可以补上UML Model）
1.权限管理无非涉及5W：Who、When、Where、What、How，不同的系统根据需求繁简而有所取舍。
Who:权限的拥用者或主体（Principal、User、Group、Role、Actor等等）
When:（State,Phase）对于复杂系统，每个对象都有一个生命周期，授权时可能要求区别对待。比如：一则新闻的生命周期可能有三个阶段：起草、审批、发布。在不同的阶段可以为不同的Who有不同的授权。
Where:（Location,Folder,Domain,Scope）对于复杂系统，有些对象可以有一个存储位置（类似于OS中的文件夹）
What：权限针对的对象或资源（Resource、Class）
How:具体的权限（Privilege、Permissioin，可以有正向与负向之分）
当然，在具体的实现时，会有很多的不同。但无非是将上面五个因素进行组合并考虑到灵活性、扩展性与可维护性。
比如：系统中可有如下对象（概念模型）：
Operator（抽象类或接口，子类有Principal,Role）
Principal（抽象类或接口，有两个子类：User,Group）
User(与Group是n:n的关系）
Group
Role（有两种子类，一种是ActorRole：Creator,Modifier,Owner,ALL等，一种是ConcreteRole，Principal与ConcreteRole是n:n关系，）
IDomain（授权的范围）
IDomainAdministrated（所有可权限管理的对象必须实现本接口，关联到Domain）
Privilege（Atom Access Permission，如：Create,ead,Modify,Delete,Revise......）
PrivilegeSet（各Privilege的集合，而以方便的实现Privilege的运算：invoke,grant,has等，多为快捷的位运算，其功能也可以与Privilege实现并合并为一个类,此时Atom的Privilege简化为一个整数：Privilege.MODIFY=lL<<2）
Authorization（或ACLEntry或AcessPolicy)=Domain+Operator+ResouceClass+State+PrivilegeSet
2.Role还是很有必要的，这样把具体的用户和组从权限中解放出来。一个用户可以承担不同的角色，从而实现授权的灵活性。当然，Group也可以实现类似的功能。但实际业务中，Group划分多以行政组织结构或业务功能划分；如果为了权限管理强行将一个用户加入不同的组，会导致管理的复杂性。
3.Domain的应用。为了授权更灵活，很多系统将Where或者Scope抽象出来，称之为Domain，真正的授权是在Domain的范围内进行，具体的Resource将分属于不同的Domain。比如：一个新闻机构有国内与国外两在分支，两大分支内又都有不同的资源（体育类、生活类、时事政治类）。假如所有国内新闻的权限规则都是一样的，所有国外新闻的权限规则也相同。则可以建立两个域，分别授权，然后只要将各类新闻与不同的域关联，受域上的权限控制，从而使之简化。
4.权限系统还应该考虑将功能性的授权与资源性的授权分开。在第一个系统中对此有所尝试，但不是很成功。很多系统都只有对系统中的数据（资源）的维护有权限控制，但没有对系统功能的权限控制。我想，好的权限系统应该考虑这一点。比如：不同的功能模块的可使用性，不同的功能（如报表功能、打印功能）的可使用性。
5.权限系统最好是可以分层管理而不是集中管理。有些大的集团公司希望不同的部门能且仅能管理其部门内部的事务，而不是什么都需要一个集中的Administrator或Administrators组来管理。虽然你可以将不同部门的人都加入Administrators组，但他们的权限过大，可以管理整个系统资源而不是该部门资源。
6.一般权限与特殊权限：即全面所讲的粗粒度权限与细粒度权限。第1点中举的例子是一般权限（或称静态权限），它是针对某范围内一类对象授权。在实际系统中，可能需要对某特定对象授权。这时的要素简化为：
Who
What
How
具体的模型对象可包括（第1点上补充）：
AdhocAccessControled（所有需要特殊权限管理的对象应该实现）
AdHocAuthorization=Operator+ResourceObject+PrivilegeSet（注意，这儿是ResourceObject而非ResourceClass）
7.正向授权与负向授权：正向授权在开始时假定主体没有任何权限，然后根据需要授予权限，适合于权限要求严格的系统。负向授权在开始时假定主体有所有权限，然后将某些特殊权限收回。当然，有些系统两种都使用，但负向权限优先。
8.权限计算策略：复杂系统中User,Group,Role都可以授权，权限可以有正负向之分，在计算用户的净权限时定义一套策略。比如主体优先顺序：User、Group、Role；权限优先顺序：-、+
9.系统中应该有一个集中管理权限的AccessService，负责权限的维护（业务管理员、安全管理模块）与使用（最终用户、各功能模块），该AccessService在实现时要同时考虑一般权限与特殊权限。虽然在具体实现上你可以有很多，比如用Proxy模式，但应该使这些Proxy依赖于AccessService。各模块功能中调用AccessService来检查是否有相应的权限。所以说，权限管理不是安全管理模块自己一个人的事情，而是与系统各功能模块都有关系。每个功能模块的开发人员都应该熟悉安全管理模块，当然，也要从业务上熟悉本模块的安全规则。
10.关于哪些是管理员可以定义的。在需求分析时就应该确定系统有哪些Privilege，以及系统安全的Policy（业务）。业务规则可以在以后根据需要通过安全管理模块定义，但Privilege定义后不可能如有些人讲的还可以在不改变代码的基础上重新定义，因为它已经散布在各功能模块内了，不管你用什么模式。比如：修改一个对象时一定要有修改的权限，在功能中会判断当前用户有没有该对象的修改权限。以后你可以通过界面定义一个新权限“万能权限”并授给某用户某类对象的“万能权限”，但该功能模块Check的还是当前用户是否有修改的权限。所以，其它的所有东西都可以自己定义，但Privilege不可以。因为到了一个具体功能里面需要知道的只有：当前用户、当前对象、所需权限。前面所有的定义最后都要解析到这三个对象。当然，这儿讨论的还是资源的安全，而非功能的安全。
姑妄言之，由于时间的原因，可能讲得比较混乱，但愿能以其昏昏，使人昭昭。