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

经常和周边软件开发的朋友、网友 ，甚至还有不懂计算机的朋友们聊“权限管理”。有些朋友对权限管理理解非常透彻，有些朋友对有些概念模糊不清。这里将我遇到的问题总结一下，供大家参考。欢迎拍砖！

 

1，“权限系统是否有加密功能”。 呵呵，这一般是不懂计算机的人说的。他们联想路线图是：权限--->安全--->加密。加密属于安全，加密是将明文通过算法转化为密文，不属于权限管理。

 

2，“哦，就是用户管理系统啊”。这是将用户管理系统当作权限管理系统。这也是不对的。权限基本都是基于用户的，这个用户有什么权限，那个用户有什么权限。用户管理系统，只是将用户管理起来。（权限可以是不局限于用户的，可以是某个网站使用另一个网站资源，一台计算机权限，一个线程权限等，这个按下不表）

 

3，“哦，就是用户－角色－权限嘛”。这个属于权限管理范畴，但权限管理范畴已经远远扩大了。比如审核员和高级审核员都能审核财务数据，但审核权限肯定是不同的。资金达到一定规模的财务数据，只有高级审核员才能审查。这个资金限度，可能还会和行业有关呢。比如：钢铁行业限额是1000万，零售行业限额是50万。

 

4，“细粒度权限和业务紧密关联，将细粒度权限抽象起来管理，这是不可能的”。这句话说对了一大半，只要将后面改为“这是很难的”就全对了。广大开发者都在孜孜不倦的寻找好的办法来解决这个事情。XACML规范听说制定了都10年多了（我没有考证，呵呵，有点懒），Oracle Entitlement Server（原来是BEA AquaLogic Enterprise Security）也有几年的历史了。IBM1996年收购了Tivoli，这也有写年头了吧。中国本土产品效方为安Metadmin Access Manager，都实现了通过界面来管理授权策略，不需要写程序。

 

5，“细粒度权限是业务方法，不是权限”。这个我不敢完全说对或者错。以前这方面缺少好的方法，将权限从业务中解开耦合，对其进行封装，所以不好实现。大多采用硬编码。随着时代进步了，这部分功能可以做了。那么如果这个划入权限管理范畴，业务代码不是变的简单、纯粹了嘛！多好啊。将细粒度权限划入权限吧。

 

6，“机构层级查询怎么做呢”。这显然有点急性子。按机构层级查询、维护数据，只是细粒度权限中的一个需求。细粒度权限应该而且必须实现这个需求。但我建议设计权限系统的设计师们，不要抱着这个不放。将这个机构当作一个纬度（而且在权限系统里面应该是一个无意义的纬度，也就是说和其他的纬度没有什么区别，没有特殊性），这样权限系统的可扩展性会更好一些。

 

7，“数据查询不是权限”。这个在中国企业里面，很多人都会认为是权限。比如总经理能查询什么数据，部门经理又能查询什么数据。这当然要授权啊。不过一些外企，反而认为这是业务方法，不做处理。Oracle Entitlement Server和IBM Tivoli Access Manager认为这是业务方法。他们产品只提供了“决策权限”，也就是只返回“true/false”那种。还好Metadmin Access Manager是在中国长大的，认为“查询权限”是权限，所以实现了这个需求。

 

 

目前，我遇到的基本就这些。欢迎大家讨论，拍砖！

 

 

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

权限管理圈子，专门讨论权限管理问题，欢迎大家加入！

http://accessmanager.group.iteye.com/

评论

55 楼 timshaw9791 2009-10-10  

yangyi 写道

我认为销售人员是岗位而不是角色，角色是一系列权限的集合，而岗位是属于基础数据的范畴，所以这里角色的定义是
角色：{
  修改用户资料：否,
  其他：可
}
置于角色到底需不需要分出层级，这个就是仁者见仁，淫者见淫的话题了

我觉得这里有几个概念需要梳理一下：岗位，职务，职位，权限，角色。
我的理解是这样的：
毫无疑问，权限是这些概念中的最细粒度的一个东西，
而角色是一组权限的集合。
岗位是职位的同义词，他们的侧重点不同。
职务才是被大家忽略的一个概念：
具体我不知道他是怎么定义的，但是我认为他是某一业务中某一角色应当承担的责任或者说应该负责的事。
而一个职位一般来说有多个职务，比如说我们的经理助理这么一个"职位"他可能要负责的事情可能有很多类：
如，协助安排经理的日程，对下面呈上来的某类报告做初步审理等等一条条。这些被我们认为梳理出来的一条条的东西就是职务 - 他在当前职位上需要担负的义务。
大家初期容易将岗位抽象成一个角色，但是最终发现这个角色可能粒度太粗或者是不宜重用，这个时候就应该梳理一下每个职位的职务，以职务为单位抽象成角色，这样才能制定出更细粒度更好重用的角色。

当然职位由于他是我们看的见摸得着的，所以直接将职位映射成角色是非常简单清晰没有异议的，而职务就不同了，他需要我们it人员深入理解客户的业务，这样才能根据客户的业务情况梳理出一个业务职务体系，这个过程必然会很辛苦。

另外我认为角色绝绝大多数情况是不需要分级和分层的。RBAC中居然还用了derive，inheritance这样的字眼来描述两个角色之间可能存在的关系，我觉得这是一个错误。现代组织中为了完成业务，大多推崇的是分工合作，就是说一个团队中每个人的角色/职责是很清楚的，而不是一种早期“经理有权做手下小兵A能做的任何事情”，实际上企业的要求是“小斌A应该干这个，经理B应该干这个”，不能越级上访，同样也不能越俎代庖！即使现在不是这个样子也会朝着这个趋势发展。如果承认这一点，那角色间就不可能存在继承关系，顶多是一些组合关系。ＲＢＡＣ中列举里例子更是把这个缺陷暴露无疑了：
书上举得例子是说Cardiologist和Oncologist本身就是Physician，所以他们具有Physician的所有权限
Cardiologist        Oncologist
        \             /
         \           /
            Physician
               |
               | Accounts receivable clerk
               |
             Resident

这个例子不能令人新服指出是他把Physician，Resident，clerk抽象成了一个个"角色Role"的同时，违背了RBAC的Role的本意 - “角色是一组权限(Permission)的集合”。Role是权限的集合，而不是属于角色的用户们的一种关系的表达，跟用户是什么身份没有任何关系，如果有关系，也是反过来：用户的身份和角色有关系。


我枉自猜测会出现这么一个问题的原因是： RABC当时如日中天，大家都认为找到了真理。手里握着锤子，就习惯把一切柱状物看成是钉子。ABAC的概念估计就是被锤子锤的受不了才出现的 ^_^ .而实际上这个权限的例子可以很好的用(RABC)Attribute-based Access Control来表达.

54 楼 lz562065806 2009-08-17  

说实在的技术上对我没有什么帮助，不过让我更加感性的认识了权限管理。
技术这个东西其实也有主观意识的。有的人认为是这样，有的人认为是那样。
不像柯南，真相只有一个。

53 楼 blackchoc 2009-07-21  

我有个问题，现在出了metadmin这样的产品有开源的细粒度权限管理的东西吗？

52 楼 dolphin_1980 2009-06-18  

细粒度的划分根据业务 需求来做，最好是放在业务层来控制

51 楼 dongliwei122 2009-04-21  

大部分赞同，但是后边说的“查询”是否要作为一个权限，我认为查询应该做为权限，比如管理员给张三开了一个临时权限其功能是只能查看某些模块，感觉“查询”作为细粒度的授权应该是很有必要的。

50 楼 metadmin 2009-04-21  

完全期待某个模型，把资源定义起来很难。

XACML采用语言的形势，对各种模型进行描述的。
可参考XACML。

49 楼 abin30 2009-04-18  

这个资源实在是不好定义啊，就和前边谈到的策略一样，，看起来简单，实际操作复杂、

48 楼 VonNeumann 2009-04-17  

GonnaFlyNow 写道

yangyi 写道

3 实际上还是角色，概念混淆

有些权限需求确实超出了单纯的角色范围。
除了判断用户的角色，还需要加上其他的判断条件。这些条件可以针对
1.当前用户属性
2.要操作的业务数据属性
3.运行环境属性

比如我以前参与开发的一个项目，有这样的权限需求：
1.入职不满3个月的销售人员（角色）不允许修改客户资料。这里“3个月”就是对用户属性“入职时间”的限制
2.销售人员只能修改自己的客户资料。这里“自己的”就是对要操作的业务数据（客户资料）的“owner”属性的限制
3.股票交易员只能在“9：30-11：30”和“13：30-15:30”买卖股票。这里“9：30-11：30”和“13：30-15:30”就是对运行环境属性“时间”的限制

我想，上面这些例子每一个都应该算楼主说的细粒度权限判断，对于这类复杂的权限需求，光靠“用户-角色-权限”，不能直接实现，BRAC的粒度还是太粗。

“用户-角色-权限-资源”就可以实现比较细力度的权限吧

47 楼 metadmin 2009-04-17  

我很期待dengtl指出错误之处呢。或许您有些误解了。本帖是指出“误区”的。

46 楼 metadmin 2009-04-17  

key232323 写道

GonnaFlyNow 写道

比如我以前参与开发的一个项目，有这样的权限需求：
1.入职不满3个月的销售人员（角色）不允许修改客户资料。这里“3个月”就是对用户属性“入职时间”的限制
2.销售人员只能修改自己的客户资料。这里“自己的”就是对要操作的业务数据（客户资料）的“owner”属性的限制
3.股票交易员只能在“9：30-11：30”和“13：30-15:30”买卖股票。这里“9：30-11：30”和“13：30-15:30”就是对运行环境属性“时间”的限制

我想，上面这些例子每一个都应该算楼主说的细粒度权限判断，对于这类复杂的权限需求，光靠“用户-角色-权限”，不能直接实现，BRAC的粒度还是太粗。

哈哈，一看到这样的需求，突然发现和我碰到并想解决的很类似。

我自己在除了role ****之外，还抽象了一个constraint model，和目标数据（一般是表结构的数据）进行匹配，原语描述一下
比如
1.beforeUpdate Table CUSTOMER constraint (SELECT 入职时间 > 3 month where SESSION.UID = UID)
2.同上
3.用动态语言实现constraint EXECUTE Groovy Shell Check if current time is available to do next job

您的session.uid是当前链接数据库的链接sessionid吗？应该不是吧，目前大多都使用连接池呢。

您抽取出“规则”（语法我没有细看了，呵呵，偷偷懒），由规则检验细粒度权限。对于决策类权限非常管用。

我还想看看，对于这类需求怎么解决：
1，普通审核员审查上限金额50w，中级审查员审查上限100w，高级审查员没有上限；
2，普通审查员只能查询金额低于50w的数据，中级审查员只能查询低于100w的数据，高级审查员没有上限。


--------------------------------------
欢迎大家踊跃讨论，改天将讨论内容总结一下。共享给大家。

45 楼 dengtl 2009-04-14  

这样的贴还不如不发，混淆视听。

44 楼 key232323 2009-04-13  

GonnaFlyNow 写道

yangyi 写道

3 实际上还是角色，概念混淆

有些权限需求确实超出了单纯的角色范围。
除了判断用户的角色，还需要加上其他的判断条件。这些条件可以针对
1.当前用户属性
2.要操作的业务数据属性
3.运行环境属性

比如我以前参与开发的一个项目，有这样的权限需求：
1.入职不满3个月的销售人员（角色）不允许修改客户资料。这里“3个月”就是对用户属性“入职时间”的限制
2.销售人员只能修改自己的客户资料。这里“自己的”就是对要操作的业务数据（客户资料）的“owner”属性的限制
3.股票交易员只能在“9：30-11：30”和“13：30-15:30”买卖股票。这里“9：30-11：30”和“13：30-15:30”就是对运行环境属性“时间”的限制

我想，上面这些例子每一个都应该算楼主说的细粒度权限判断，对于这类复杂的权限需求，光靠“用户-角色-权限”，不能直接实现，BRAC的粒度还是太粗。

哈哈，一看到这样的需求，突然发现和我碰到并想解决的很类似。

我自己在除了role ****之外，还抽象了一个constraint model，和目标数据（一般是表结构的数据）进行匹配，原语描述一下
比如
1.beforeUpdate Table CUSTOMER constraint (SELECT 入职时间 > 3 month where SESSION.UID = UID)
2.同上
3.用动态语言实现constraint EXECUTE Groovy Shell Check if current time is available to do next job

43 楼 metadmin 2009-04-13  

非常高兴看到XMLDB和dikar精辟的论点。

XMLDB谈到了系统管理员不能干涉业务逻辑。

XMLDB 写道

一个安全的系统
系统管理员是不能操作业务的,必须杜绝管理员监守自盗的可能.
所以把业务的规则作为权限存在,使得系统有被越权使用的风险,这是不能接受的

我非常认同这点。

XMLDB谈到的规则校验，以及dikar谈到的业务规则引擎。我认为是非常可行的，而且是很优秀的。只不过我们之间存在一个不同点：我认为业务规则这种校验属于权限，二位认为这是业务。如果和权限混在一起，会造出：系统有安全隐患（系统管理员干预业务规则）、系统模块不专一、系统可扩展性、系统效率（系统编码实现和运行效率）等等问题。

这种细粒度的是否属于权限，我们暂且放一下。先讨论一下造出的问题，然后反过来推一下。
1，系统管理员干涉业务逻辑。
当今金融危机，普通审查员审查额度上限由原来的100w降低到75w。类似这样的变动，系统应该提供一个界面，由用户来调整这个阀值，而不应该是去修改源代码。
在这里，分享一下某大型企业的管理规范，他们将系统用户分为：
   a，系统管理员；
   b，业务管理员；
   c，业务用户。
上例中审核阀值调整，一般由业务管理来调整。而且业务管理员可能还分区域呢。比如上海是某个阀值，西部又是另一个阀值。

2，系统模块不专一。
前几年我也带领开发过一些项目，这几年接触的客户项目。大多业务模块不专一，可复用率低。给客户A开发了某个系统，再给统一行业客户B开发同样的系统。本打算复用很多代码，结果发现复用起来非常麻烦。再加上项目组员变动，还不如重新开发呢，花费的代价超出了公司决策层的预期。
这又是为什么呢？业务模块不专一、复用率低，不也是一大原因吗？业务模块里面散布这if/else判断规则，这不是问题吗？
现在是“牺牲”业务模块的专一性来换取权限模块的专一性。如果能够通过“牺牲”权限模块的专一性，来换取业务模块的专一性，软件企业会采纳吗？

在metadmin软件哲学看来，业务模块应该是基于基本数据库增加、删除、修改操作基础上，按照业务流程将这些操作串起来。

3，系统可扩展性、系统效率
如果认清楚了第二个问题的解答，这个问题自然迎刃而解了。

关于“这种细粒度的是否属于权限”，可以参考一下XACML规范，以及Oracle Entitlement Server和IBM Tivoli Access Manager。他们就是干这事的，我想他们多多少少还是很权威的。

42 楼 dikar 2009-04-12  

我说下现在公司的权限系统设计供大家参考：

这里分  权限 角色  组织  用户 四大实体

某主体是否能对某资源进行操作 是依据他的权限来判断的（当然这是废话了）。

那这个主体是怎么获得权限的呢 ？

现在的设计是  让主体扮演某些角色   然后我们针对角色来分配权限 。
这一主体扮演这个角色 然后这个角色的权限还能使用时  你这个伪角色 就可以执行这个角色拥有的权限了 。

比如说 我是一个门卫  然后你让我扮演CEO角色 然后CEO角色有 开除 总经理的权限 ，
那ok 当门卫 去开除总经理的时候 就拥有了权限 。

针对组织来说就是我给这一组织分配某一角色  然后只要是这个组织里的员工就能扮演这一角色  也即拥有该权限。


一个设计好的权限系统 针对权限主体 应该做一些划分 比如说单个实体 某一群体 等等，好比这里的用户 、组 。

组织的概念 并不完全等同于 实际的部门 ，只能说组织的概念更大一些 ，比如包含 虚拟组织 实际组织（真正的部门） ，虚拟组织中可以包含有其他各个组织中的成员 好比我临时搭建了一个动员小组去铲平小日本，里面有门卫 、开发、测试等等实际部门中的人。


针对帖子中提到的 大于 10000金额的 只能由具有总经理权限的人 （举个例子 有N多不干事的总经理 可以审批）来审批这样的 业务逻辑，其实不能算是 权限里的东西 ，我这里说的是具有总经理权限的人 而不是简单的说就是总经理，意思是想告诉大家 我们的程序不要太死了，其实我们面对的是一群抽象的对象，而不是真正意义上的实体，好比 突然总经理全部离职 现在需要审批某一很急的账务  那现在我这个门卫可以审批了，你怎么办 ？
这个东西最初 我们都是在代码里判断的或者说在sql里判断的 ，然后慢慢地大家发现业务规则越来越多，而且规则实施的顺序也在不断变化，因此有些人终于受不了了，开始研究一套系统，叫什么呢？规则引擎 ，然后像这样 金额>10000 .入职大于3个月 等这样的业务规则被放在规则引擎里维护 ，业务规则被很好的维护起来了，至于里面需要用到权限判断的 就可以调用你伟大的权限模块了来判断就好了。（补充一下 我说这句话的意思并不是让大家都马上去用规则引擎，不是所谓的做广告，我现在公司的系统都还是在程序里做的判断，这里只是给出一个解决方案而已，有的时候系统改造需要考虑遗留系统的影响 和改造的成本等等）

总结一下：首先说明一下 ，以上观点和以下观点纯属我个人YY ，说的不对的 或者 大家认为我胡言论语 伤害到你们的，我赔个不是，再就是我例子中用到很多现实的角色比如 门卫 总经理等纯属虚构 ，大家不要对号入座 只是举个例子供大家理解而已，谢谢。

1：设计任何系统的时候 首先需要定位这个系统核心的功能是什么，比如说权限系统 ，你把业务规则也拿进来 你可以做吗 ，好吧你牛可以做 ，那你是不是做出来很费劲然后可扩展性很差呢 ，所以系统要设计地精简 专一 。权限是不能和业务相关的。

2：能做并不代表你可以这么做 ，有的时候我们需要衡量代价 ，你可以做但是效果很差 然后累个半死 那就是吃力不讨好。

3：做系统要理解面向对象，即使你不能很好的理解 也要考虑某些情况下你的系统能否很好的应对，当不能应对的时候你就需要进一步抽象了。

4：模块化地设计 降低耦合 模块专一性。这都是套话 ，但是模块专一是我们最好理解的了。

下面我补充一点材料让大家参考一下权限相关的设计：

看一下 linux 或者unix 下的权限系统的设计 ，很优雅的设计。

看一下 oracle 中关于 数据库 用户权限的问题 ，oracle中 是依据用户 来区分你能看哪些表的 。

41 楼 XMLDB 2009-04-10  

一个安全的系统
系统管理员是不能操作业务的,必须杜绝管理员监守自盗的可能.
所以把业务的规则作为权限存在,使得系统有被越权使用的风险,这是不能接受的
理想的系统应该是这样的:
    高级领导可以定义业务规则的权限,平级或者更高级领导有审核修改业务规则的权限
    业务员操作受规则限制
    数据范围属于业务规则范围
   
    操作xxx开始:
        校验规则开始:
            校验系统权限规则
            校验业务规则
        校验规则结束
        校验通过则:
            doXXXX
        否则:
            抛异常
    操作xxx结束

40 楼 XMLDB 2009-04-10  

LucasLee 写道

Frederick 写道

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

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

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

如上面提到的

引用

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

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

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

这位是明白人,那些把业务规则搞成权限的,俺是不会用你们的系统的.

39 楼 felix.shao 2009-04-10  

 

38 楼 GonnaFlyNow 2009-04-09  

<div class="quote_title">LinuxForShare 写道</div>
<div class="quote_div">感谢GonnaFlyNow的回复<br />我们公司是一个全球30多万人的跨国集团，分地区、公司等<br />系统应该说是已经比较大了吧,许多表的数据量都是千万级的<br />权限不是我设计的，我也没达到那种水平，呵呵<br />后台数据库倒是经常操作，我最大的感受也就是数据库的设计了<br />还有，我们讨论的是权限，业务是不考虑的</div>
<p><br /><br />30多万人，绝对是大系统！<br /><br />确实，有时候真的很难区分哪些是业务，哪些是权限，毕竟权限和业务是密不可分的。<br />我想我们不必非得在这里讨论出权限和业务的划分标准，那是理论研究者干的事情。<br /><br />咱们是开发人员，只要我们的系统架构足够健壮和清晰，该模块化的模块化，该解耦合的解耦合，<br />如果能保证实现前面那些复杂需求很容易，后期维护也很简单，就ok了。</p>
<p> </p>

37 楼 metadmin 2009-04-09  

GonnaFlyNow的举例，是权限，我们也称为细粒度权限（数据级权限）。

这是权限，但和业务直接相关，业务性的权限。

36 楼 LinuxForShare 2009-04-09  

感谢GonnaFlyNow的回复
我们公司是一个全球30多万人的跨国集团，分地区、公司等
系统应该说是已经比较大了吧,许多表的数据量都是千万级的
权限不是我设计的，我也没达到那种水平，呵呵
后台数据库倒是经常操作，我最大的感受也就是数据库的设计了
还有，我们讨论的是权限，业务是不考虑的