基于kasai的RBAC框架

    基于角色访问控制已经成为业界一个标准，这方面的开源框架却不多，网上看了下Kasai是完成得比较好的一个，其它的RoleManager和RIWS，网上找到的资料较少，没有弄下来看过。

    RBAC的主要思想在于，将人与权限解耦，通过角色来达到这一目的。事实上这一模型的实现并不复杂，Kasai整个框架看完之后也没觉得它有什么出彩的地方，相反，它对数据的控制是基于单条来实现，把用户的操作复杂化了。网上有篇介绍Kasai的文章，中间提到Kasai的object表没有提供添加的入口，实际上这张表存储的就是“数据”，系统中加入数据之后，就会在该表中加入相应的记录。在Kasai的基础上，作如下改进：

1、在SaaS架构下，为满足多租户的场景，对所有业务表加上租户ID；
    这实际上是出于SaaS的考虑了，与RBAC关系不大。若系统不是基于SaaS架构可跳过。

2、角色继承、向下兼容、默认角色；
    角色继承可方便管理员，每一个角色都要从零开始添加权限，这是管理员不愿意做的事情。继承有两个考虑：一是新建角色时继承，说白了就是一个初始时数据来源的问题，一旦角色创建完成后，其与父角色不再有任何关系；二是类似于java中的继承关系，父角色的变动影响子角色。但后者无论是使用上还是实现上，都不太适合。可考虑第一种方式。
    向下兼容基于以下场景：某系统中存在三级组织架构，从上到下分为一，二，三级。某些业务场景下，一级管理员只能看到一级的数据，另一种场景下，一级管理员能看到本级及所有下级的数据。如果不从数据上加权限控制，则可通过角色的向下兼容处理。此时角色需要与部门相关联。
    假定某部门下有五个角色，可将其交集的权限抽取出来成为该部门的默认角色，方便操作。

3、数据的权限控制
    Kasai的数据权限控制是基于“数据即目标”，通过对每一条数据作权限分配来实现。这样只适用于演示，实际系统中没有可行性。一般来说应该通过对数据进行分类以达到权限控制，以公文为例，根据公文的密级来限定浏览者可看到的公文范围。考虑以下方案：
表名       字段名       规则
公文表      密级    {机密}=#role{管理员},#user{张三，李四}；

以上规则表示，公文表中字段密级为机密的，只能由管理员或张三或李四查看，其它人无权限，转化为sql即为   where condition(实际业务条件)  and (密级！=机密 or role=管理员 or 用户 in (张三，李四))
从上面可以看出，这种实现并不复杂，可将制定规则用界面展示出来供用户自定义操作。只需将界面展示得人性化一些，用户操作起来还是比较方便的。另外需要考虑的是，公文中的密级，存储的值可能是1，2，3（编码），但用户在定制时需要显示成机密，绝密，秘密等，这类工作需要定制或另起方案。