RBAC权限涉猎之关系处置
最近需要关注到RBAC这部分的理论知识。
针对一个小型的系统， 将其原有的权限设计全部推倒重来， 设计成基于RBAC。
简单的说说自己这几天的心得。主要对于RBAC中，相关概念关系的处理来说说。
开始之前，首先把自己研究的对象，kasai开源系统介绍一下。
这是一个纯java编写的权限设计框架， 与其说它是框架，还不如说它仅仅是RBAC的一个实现而已，
因为其系统内部的代码不论扩展性还是可读性都不敢恭维。
但是其将RBAC的标准给实现了，也算是一个值得研究的对象。
这里主要讲讲kasai系统中，相关概念的关系部分。
（RBAC中相关概念有： 用户、用户组、操作、角色、资源）
标准RBAC0理论中， 核心的一点就是 角色， 根据此概念再来延伸到其他部分。比如说操作。
角色与操作之间存在着关系： 某个角色可以包含多种操作 ，同样的， 一个操作可以隶属于不同的角色。
典型的示例： 管理员可具有查看操作， 普通用户也可以具有查看操作。
所以， 这两者之间的关系 其实可以看作为N:M， 也就是多对多。
资源与操作存在着关系： 权限系统设计的最终目的是将资源进行合理的分配， 防止资源的滥用。
同一种资源的话，可以与多个操作相关联起来 。 比如查看操作， 其可以查看
某个目录，也可以是某个文件。（关于kasai系统， 并没有建立这样的关系，具
体请看发上来的图片）
用户与角色存在关系： 在RBAC中， 用户是无法直接与资源打交道的，如果那样的话，那么权限也就没
任何意义了。 那么如何对资源进行处理呢？ 答案是，将用户与某个角色关联起
来，用户通过角色---> 角色通过操作----->获取操作相关的资源。 这样就将相关的
资源进行了隔离。也就有效的控制了资源的分配情况。
用户与用户组存在关系： 一般的系统中， 会将用户以某个子集的形式划分到某个用户组内，也就是某个组
织中，如A属于开发部，当然， 也有的用户可以身兼数职， 如 即是开发人员，
又是管理人员。 那么这样的关系也就意味着，用户与用户组是N:M的关系。
用户组与角色存在的关系： 有的功能，需要根据系统颗粒度不的不同，来进行不同的角色划分， 比如某种
角色可以被多个用户同时拥有， 那么系统中为了方便处理，就将此种角色，统
一赋予某个用户组， 让其组内的所有单个用户都拥有着相同角色。
再回到kasai系统中， 其内部的数据库设计大部分基于这样的关系来实现。 为了便于理解， 我将kasai的相关数据表设计重新整理一下， 放上一张图，便于理解。
如果看不清楚图，请点这里
灰色的表，即代表这关系处理， 因为在关系型数据库中，一旦有N:M的关系体现，那么通常就需要中间表来处理了。
OK， 对于RBAC中相关概念的关系，就在这里了， 这些都是个人理解。 可能还不够严谨， 如果有兴趣的朋友，欢迎一起探讨！