| « | August 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | |
|
公告 |
| 本博客在此声明所有文章均为转摘，只做资料收集使用。并无其他商业用途。 |
| Blog信息 |
|
blog名称:
日志总数:210
评论数量:205
留言数量:-19
访问次数:917937
建立时间:2007年5月10日 |
| |
|
 对权限管理认识的一些误区
文章收藏, 网上资源, 软件技术, 电脑与网络
李小白 发表于 2009/4/3 0:05:35 |
|
经常和周边软件开发的朋友、网友 ，甚至还有不懂计算机的朋友们聊“权限管理”。有些朋友对权限管理理解非常透彻，有些朋友对有些概念模糊不清。这里将我遇到的问题总结一下，供大家参考。欢迎拍砖！ 500)this.width=500'>
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是在中国长大的，认为“查询权限”是权限，所以实现了这个需求。
目前，我遇到的基本就这些。欢迎大家讨论，拍砖！
|
|
|