RBAC权限涉猎之关系处理

最近需要关注到RBAC这部分的理论知识。

      针对一个小型的系统， 将其原有的权限设计全部推倒重来， 设计成基于RBAC。

      简单的说说自己这几天的心得。主要对于RBAC中，相关概念关系的处理来说说。

      开始之前，首先把自己研究的对象，kasai开源系统介绍一下。

      这是一个纯java编写的权限设计框架， 与其说它是框架，还不如说它仅仅是RBAC的一个实现而已，

      因为其系统内部的代码不论扩展性还是可读性都不敢恭维。

      但是其将RBAC的标准给实现了，也算是一个值得研究的对象。

   

      这里主要讲讲kasai系统中，相关概念的关系部分。

       （RBAC中相关概念有： 用户、用户组、操作、角色、资源）

      标准RBAC0理论中， 核心的一点就是 角色， 根据此概念再来延伸到其他部分。比如说操作。

      

           角色与操作之间存在着关系： 某个角色可以包含多种操作 ，同样的， 一个操作可以隶属于不同的角色。

                                                    典型的示例：  管理员可具有查看操作，  普通用户也可以具有查看操作。

                                                     所以， 这两者之间的关系 其实可以看作为N:M， 也就是多对多。

           资源与操作存在着关系：    权限系统设计的最终目的是将资源进行合理的分配， 防止资源的滥用。

                                                    同一种资源的话，可以与多个操作相关联起来 。 比如查看操作， 其可以查看

                                                    某个目录，也可以是某个文件。（关于kasai系统， 并没有建立这样的关系，具

                                                      体请看发上来的图片）

         

           用户与角色存在关系：       在RBAC中， 用户是无法直接与资源打交道的，如果那样的话，那么权限也就没

                                                  任何意义了。 那么如何对资源进行处理呢？ 答案是，将用户与某个角色关联起

                                                  来，用户通过角色---> 角色通过操作----->获取操作相关的资源。 这样就将相关的

                                                  资源进行了隔离。也就有效的控制了资源的分配情况。

          用户与用户组存在关系：    一般的系统中， 会将用户以某个子集的形式划分到某个用户组内，也就是某个组

                                                 织中，如A属于开发部，当然， 也有的用户可以身兼数职， 如 即是开发人员，

                                                又是管理人员。 那么这样的关系也就意味着，用户与用户组是N:M的关系。

          

           用户组与角色存在的关系： 有的功能，需要根据系统颗粒度不的不同，来进行不同的角色划分， 比如某种

                                                    角色可以被多个用户同时拥有， 那么系统中为了方便处理，就将此种角色，统

                                                   一赋予某个用户组， 让其组内的所有单个用户都拥有着相同角色。

          再回到kasai系统中， 其内部的数据库设计大部分基于这样的关系来实现。 为了便于理解， 我将kasai的相关数据表设计重新整理一下， 放上一张图，便于理解。

          

          

   如果看不清楚图，请点这里

 

           灰色的表，即代表这关系处理， 因为在关系型数据库中，一旦有N:M的关系体现，那么通常就需要中间表来处理了。

        

         OK， 对于RBAC中相关概念的关系，就在这里了， 这些都是个人理解。 可能还不够严谨， 如果有兴趣的朋友，欢迎一起探讨！