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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

我非常认同这点。

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

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

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

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

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

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

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

我自己在除了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的数据，高级审查员没有上限。


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

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

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

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