对权限管理认识的一些误区

这个问题，可以分为2个部分：1，用户身份集中管理和认证；2，用户权限信息管理。

用户身份信息，我建议集中管理，这样免去信息冗余，而且只要在一个地方维护，而不是多个系统同步维护；
用户权限信息，集中管理和分散在各个系统管理，都可以。集中管理当然很好，只是担心工作量大，给各个系统权限判断造出麻烦。

Oracle Entitlement Server和IBM Tivoli Access Manager是将所有系统的权限集中起来管理。可以参考一下他们的设计思路。

其实不用搞这么复杂，说白了，权限是什么？那么先要搞清楚什么叫权限主体（Principal），什么叫资源主体（Subject），什么叫动作（Action）？权限就是哪些权限主体对哪些资源主体可以执行哪些动作。这里的权限主体，不一定非得是什么人、岗位、组等组织机构实体，它可以是任何东西，例如服务器A，是否可以在读写磁盘柜上的文件，服务器A就是权限主体。

这里小弟给出XACML标准中针对权限相关概念的说明，供大家参考：

1.Subject - 主体。就是权限中执行操作Action的实体，可以是登录用户，进程或其他东西

2.Resource - 资源。Subject要访问的数据，服务或系统组件，在应用系统中，一般是业务数，比如员工，订单等

3.Action - Subject对Resource的具体操作，比如增加，删除，修改，查看，审核，预订等

4.Police - 授权策略。即Subject-Action-Resource的组合。 定义什么样的主体能对什么样的资源执行什么操作。比如：销售人员（Subject）只能查看（Action）自己的客户信息（Resource）。

权限从概念上看很确实不复杂，其核心就是对授权策略Police的定义，不过在实现具体权限需求时，特别是细粒度权限，往往要求Subject和Resource满足特定的条件，这时权限逻辑就会变得复杂了。比如：

1.Police - 入职不满3个月的销售人员不允许修改客户资料。这里“入职3个月”就是对Subject销售人员的进一步限制

2.Police - 初级合同审核员只能审核10000元以下合同。这里“10000元以下”就是对Resource合同的进一步限制

这种思路很好， 我也认为应该分为两部分，但是是用户身份管理和用户权限管理。至于是不是集中管理，很多时候是由用业务系统决定的，如：证券公司和银行的系统就一般就无法进行集中管理身份，而是通过身份映射来实现。权限完全可以由业务系统自己控制。我对CA的SiteMinder比较熟悉， IBM的TAM产品应该基本思路是一样的，权限是不是集中，就看PS怎么管理了。 多个系统的帐号同步的问题确实很复杂的，这个涉及到IdM的问题。呵呵，怎么越说越多了。就到这里吧。希望多交流。

细粒度权限控制如何从业务中抽象出来，这是个问题，我正在为这个头疼。个人感觉完全抽象出来根本没有可能性。

我有个项目使用spring security实现细粒度权限。spring倒是把权限管理从业务中提取出来了，不过所有的权限逻辑还是需要自己写voter来实现，感觉不是很爽。另外spring security学习梯度很大，手下几个程序员跟进很慢。

这几天看了楼主的权限管理圈子里的文章和 Metadmin 演示， 觉得这个产品挺不错的。不但实现了权限和业务的解耦合，同时支持用配置的方式实现权限判断逻辑，不用编码。

Oracle和IBM的权限管理产品还没有研究过，不知道好不好用，等研究好了再跟大家分享。

我经历的很多项目在讨论这部分时主题是权限管理，但常常关心用户管理，同时也不会忘记角色管理，因为角色通常被用来做为权限的载体、集合，这就是楼上各位提到的“权限--角色--用户”。
这种方式没有领会权限管理的核心，但确是常用的。
我觉得如GonnaFlyNow所说，Police才是我们解决权限问题的关键，单单说权限本身没有啥，关键是我们如何定义Police，如何定义Police简捷、方便。

我也没有做过将细粒度权限抽象出来的系统。
我做的就是将CRUD等业务权限和数据范围抽象出来。

你不妨说说哪些细粒度权限难以抽象出来？
我觉得这方面还挺有意思，我看还是有可能抽象出来的。

如上面提到的
我觉得这个似乎挺适合用规则引擎来处理，这东西跟打折促销、老客户折扣这类规则听类似的。
不过还没研究过。

实质上权限管理,我的认为是:"角色分配"

趁这几天活不多，研究了一下 Oracle ，IBM 以及 Metadmin，发现他们对细粒度权限的支持就是通过定义规则来实现的。
比如要实现“入职不满3个月的销售人员不允许修改客户资料”，步骤是：

1.定义规则

rule1：员工.入职时间 > 3个月

 

rule2：

if(rule1==true){
   允许修改客户资料
}else{
   不允许
}.

2.在运行时刻，规则引擎会对rule1和rule2进行评估，最终返回评估结果（允许或拒绝）

 

 

在规则的表示上，三家使用了不同的方式

 

IBM 用 XSL 语法来描述

Oracle 用 XACML 来描述

Metadmin 通过图形界面配置产生