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

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

 

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/

评论

15 楼 metadmin 2009-04-03  

<p>这个帖子有些跑题了：我们不是来探讨哪个技术好，哪个技术逊。<br /><br />而是探讨 <span style="text-decoration: underline;"><strong><span style="font-size: x-large;">对权限认识的误区</span></strong></span>。</p>
<p> </p>
<p>我们都回到这个主题上来吧。</p>

14 楼 metadmin 2009-04-03  

感谢yangyi的肯定！

在易用性上，不是很好。这不是Spring Security才有这种情况，世界上充斥着很多复杂的东东。很多项目也是这样。当年，我在学徒的时候（哈哈，刚毕业的时候，有师傅带着做。呵呵，幸福）师傅给我灌输了很多知识。那个时候就是羡慕、崇拜。

后来，自己做了高级程序员。经理让我设计一个日志系统。天哪，我苦思冥想了1个多星期。搞了一个复杂的东东。经理没有看懂。将我的设计废了。然后把Log4j的链接给我。

天哪，那个时候，有种“被青春撞了一下腰”的感觉。这么简单，配置好了，就随便debug,info。想哪里用就哪里用。唯一需要注意的地方就是（打这种拼接日志，最好先做个判断）：
if( logger.isDebugEnabled() ) {
  logger.debug( "some text" + obj.getSomeAttribute() + .. + ..;
}

13 楼 GonnaFlyNow 2009-04-03  

yangyi 写道

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

完全同意，本质上销售人员是岗位而不是角色。不过大部分系统中岗位和角色概念重合的情况确实很多，因为最终用户已经习惯将岗位定义成角色了，为了让用户好理解，也只能迎合。呵呵

12 楼 agile_boy 2009-04-03  

jsecurity中permission和role还是有清晰的

11 楼 yangyi 2009-04-03  

metadmin 写道

GonnaFlyNow 写道

yangyi 写道

4-7 java的话spring security就可以实现

谈到实现，spring security确实可以实现，不过小弟认为spring security只提出了一个框架，要实现细粒度则需要实现voter接口，并且通过xml配置进来，还是比较复杂的。

如果能将权限和业务耦合解开，将分散在系统中各个权限逻辑集中起来管理。这是一种好的系统架构方式。
如果实现这种权限逻辑很复杂，在有些情况下，还不如自己手工编码呢！所以权限系统应该简单，而不是复杂。如果是复杂，就相当于用一种复杂方式替换了另一种复杂方式。


欢迎您进入权限管理圈子看看：
http://accessmanager.group.iteye.com/

并多留意本土产品Metadmin Access Manager。非常简单易操作的。。

首先您把问题考虑的这么全面，说明这个产品是下了功夫的，对于spring Security，可以通过简单的扩展+AOP简化配置，不过易用性上肯定要差一些，好在不是所有人都需要掌握

10 楼 yangyi 2009-04-03  

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的粒度还是太粗。

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

9 楼 metadmin 2009-04-02  

GonnaFlyNow 写道

yangyi 写道

4-7 java的话spring security就可以实现

谈到实现，spring security确实可以实现，不过小弟认为spring security只提出了一个框架，要实现细粒度则需要实现voter接口，并且通过xml配置进来，还是比较复杂的。

如果能将权限和业务耦合解开，将分散在系统中各个权限逻辑集中起来管理。这是一种好的系统架构方式。
如果实现这种权限逻辑很复杂，在有些情况下，还不如自己手工编码呢！所以权限系统应该简单，而不是复杂。如果是复杂，就相当于用一种复杂方式替换了另一种复杂方式。


欢迎您进入权限管理圈子看看：
http://accessmanager.group.iteye.com/

并多留意本土产品Metadmin Access Manager。非常简单易操作的。。

8 楼 GonnaFlyNow 2009-04-02  

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的粒度还是太粗。

7 楼 GonnaFlyNow 2009-04-02  

yangyi 写道

4-7 java的话spring security就可以实现

谈到实现，spring security确实可以实现，不过小弟认为spring security只提出了一个框架，要实现细粒度则需要实现voter接口，并且通过xml配置进来，还是比较复杂的。

6 楼 caryl 2009-04-02  

引用

caryl 写道
如果我针对某个角色定义只能查看自己的订单，这种控制才是权限。

这句话我没有理解，什么意思呢？

我的意思是：查询本身不是权限所关注的，跟角色相关的查询的限制条件才是权限要解决的问题。

5 楼 metadmin 2009-04-02  

caryl 写道

同意楼主处理数据权限的方式(通过控制查询)，但我认为数据查询确实不是权限。数据级的权限定义应该只是数据查询的某些条件。比如我在某页面想查看订单的信息，包括订单名称，订单项目，总金额等，这是业务方法。如果我针对某个角色定义只能查看自己的订单，这种控制才是权限。

这点也同意你的看法：查询条件是权限控制要素；执行查询语句，封装JAVA对象是业务方法。
但，某些用户只能查询某些列，某些用户又能查询另外的列。这些也属于权限控制呢。这就是我们达成共识的“列级”。

caryl 写道

如果我针对某个角色定义只能查看自己的订单，这种控制才是权限。

这句话我没有理解，什么意思呢？

4 楼 metadmin 2009-04-02  

caryl 写道

我也谈一下我对权限系统的理解，跟楼主探讨。
我认为权限可以分为以下几种：
1、功能级权限，这个比较常见，控制可以访问哪些功能，最常见的是使用RBAC模型来做的。
2、数据级权限，OO一点的话常被称为实例级权限、面向数据库一些的常被称为行级权限，应该就是楼主说的“细粒度权限”。即在某功能中控制角色可以访问哪些数据，这个也有好几种实现，我比较倾向于类似楼主的处理方法，拼sql语句进行过滤，这样处理起来更方便一些，特别是针对列表分页的情况。
3、属性级权限，如果更细一点，还可能会有这种情况，如对于订单，库管员只能查看数量，不能查看金额；某角色只能修改数量，不能修改单价。
4、其他权限控制，如仅内网ip可以访问，仅限工作日可以访问等。这类权限视情况也可以和功能级权限一起处理。

2和3的权限如果想处理的比较通用，我认为还是应该通过针对元数据的定义来实现，这一点应该类似楼主的做法。

先来探讨这个问题，这个要简单一些。呵呵。

我完全同意你的观点。
如果是查询的话：权限应该是行级（查询到多少条数据），列级（查询到哪些字段）。

授权要素可能是：1，用户属性；2，被操作数据属性；3，当前环境数据（时间、地点等）。

同时，我们要注意：同一个业务操作，对于不同用户的权限模型可能是不同的。
你的例子很对，我也贡献几个例子：
1，管理员只能是周一到周五上班时间登录系统；
2，管理员只能在内网登录系统；
3，其他人无限制。

从数据操作方向（读取数据，向数据库同步数据）来说，可以将细粒度权限这么分类：
1，细粒度查询权限（行列级）；
2，细粒度决策权限。

3 楼 丁丁豆 2009-04-02  

不是太明白

2 楼 caryl 2009-04-02  

楼主列出的这些问题还是比较有代表性的，也是比较常见的几个权限方面的问题，对以下几点跟楼主探讨：

引用

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

认同楼主的这个观点，组织机构的定义和权限系统中角色并没有直接关系，两者并不是一个层面的东西。还有一种观点认为组织机构的“职位”就是权限系统中的“角色”，我不认同这种观点。

引用

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

同意楼主处理数据权限的方式(通过控制查询)，但我认为数据查询确实不是权限。数据级的权限定义应该只是数据查询的某些条件。比如我在某页面想查看订单的信息，包括订单名称，订单项目，总金额等，这是业务方法。如果我针对某个角色定义只能查看自己的订单，这种控制才是权限。

我也谈一下我对权限系统的理解，跟楼主探讨。
我认为权限可以分为以下几种：
1、功能级权限，这个比较常见，控制可以访问哪些功能，最常见的是使用RBAC模型来做的。
2、数据级权限，OO一点的话常被称为实例级权限、面向数据库一些的常被称为行级权限，应该就是楼主说的“细粒度权限”。即在某功能中控制角色可以访问哪些数据，这个也有好几种实现，我比较倾向于类似楼主的处理方法，拼sql语句进行过滤，这样处理起来更方便一些，特别是针对列表分页的情况。
3、属性级权限，如果更细一点，还可能会有这种情况，如对于订单，库管员只能查看数量，不能查看金额；某角色只能修改数量，不能修改单价。
4、其他权限控制，如仅内网ip可以访问，仅限工作日可以访问等。这类权限视情况也可以和功能级权限一起处理。

2和3的权限如果想处理的比较通用，我认为还是应该通过针对元数据的定义来实现，这一点应该类似楼主的做法。

1 楼 yangyi 2009-04-02  

1，2不说了
3 实际上还是角色，概念混淆
4-7 java的话spring security就可以实现