权限RBAC模型的一些疑问,顺便放分
RBAC提到的概念是用户->角色->权限,权限是由resource和operation组成的.
1.我的问题是如何理解resouce + operation呢?
2.是不是可以理解为操作级权限(具体到每一个功能)?
3.我的目的是想做出操作级权限,如果是这样的话请麻烦把权限对应的resource+ operation表帮忙设计一下,或者指点一下.
注:框架的配置或实现就不需要了,毕竟不是自己的东西.
谢谢



------解决方案--------------------
角色和用户中间表 对应 resource operation中间表 因为这2者都是多对多关系 

一句话说就是 用户在某种角色下面 对某种资源 有某种操作 （增删改查） 有空了 出篇文章 相互讨论下！
------解决方案--------------------
帮顶， 等楼上的文章了
------解决方案--------------------
起码要五张表 两个中间表，我用的更多，设计了7张表！把我设计美了！哈哈
------解决方案--------------------
学习学习~~！
------解决方案--------------------

探讨

我原始的模型是这样的
用户->用户角色(中间)->角色->角色权限->权限(这个表就是所谓的功能 比如:save\delete\update\query\find等)

看你的说法感觉是这样的

用户->用户角色(中间)->角色->角色权限(中间)->权限(资源表 也就是类)->操作表(operation也就是具体的每个类的增加之类的)

然后权限和操作表之间是一对多的关系.

是对的么 如果不对请帮忙在原始模型上加..分好说

------解决方案--------------------
1.我的问题是如何理解resouce + operation呢? 
rbac定义是：resouce + operation = 权限
如：申报单资源 + 修改操作 = 申报单修改权限

2.是不是可以理解为操作级权限(具体到每一个功能)? 
不是，rbac的资源是业务含义的，比如说上面的申报单

“用户->用户角色(中间)->角色->角色权限->权限(这个表就是所谓的功能 比如:save\delete\update\query\find等) 
用户->用户角色(中间)->角色->角色权限(中间)->权限(资源表 也就是类)->操作表(operation也就是具体的每个类的增加之类的)”
这两种都不尽正确。B/S应用的权限控制有两种实现方式：url过滤、aop拦截。你的权限表粒度一直到了操作级别（save\delete...），那么在实现上你就得斟酌了，如果用url过滤方式，那么url是不一定能体现出操作的。比如客户使用struts的普通action，使用operFlag传参来确定执行增删改查哪一个方法，那么客户的哪个operFlag表示增？是add？还是insert？你不能确定，也不应限制客户必须用哪个。如果使用dispatchAction，方法名就一定体现操作吗？也不一定。即使你限制了，那么url过滤时的解析又是问题，客户端operFlag传参是第几个？这都是不确定因素。如果用aop拦截方式，也有同样的问题。
类不是资源。
做到操作级别控制的权限本身就值得商榷，因为你要做到这么细的粒度，前提就是默认不允许用户访问所有方法，只有配置上了权限才允许访问，那么使用你的权限系统仅大量的配置就足以让客户疯掉了。