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

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

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

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

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

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

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

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

当然职位由于他是我们看的见摸得着的，所以直接将职位映射成角色是非常简单清晰没有异议的，而职务就不同了，他需要我们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来表达.