权限设计总结

原创
2016/03/28 22:51
阅读数 1.8K

    业务系统除了具体的业务之外,最麻烦的就是对于每个成员权限的控制了。最近收拾东西,忽然飘出一张几个月前,进行权限表设计的思路,我觉得还是比较普适的,所以来总结一下。

    权限的控制要么是ACL要么是RBAC,他们具体的介绍看这里

    那么我的设计是RBAC的,既基于角色的访问控制,直接上例子吧。

    为了避免没人看,我把特点或者说优点放在前面吧:

    1)可以针对不同的实体创建不同的权限限制(实体是指如订单、商品等业务实体)。

    2)针对某实体的权力可拓展,针对某实体的权力等级大小也可拓展。

    3)支持多角色用户。

    4)角色可控制不同的实体。

    5)换言之,用户对所有实体都有不同的权限控制。


    以下表字段一切从简,维护性字段就不写了。

    1、首先我们得有个用户表,上面随便弄一些基本属性,以username为主键

    

    2、其次角色表得有吧,来一发角色表。

    

    3、那么考虑到多角色的情况,角色就不能作为一个字段在user表中,角色和用户的关系表得有吧

    

    4、下面就是跟别的权限设计不太一样的地方了,我实现将可能的操作尽可能穷举,那么就设计成酱紫了的一个表。   

    

    简单的介绍一下,我弄了一个表称为实体表(entity),它与角色,权力形成一个关系表,称为角色实体权限表吧(简称REP表)。REP表中穷举了可能有的权力,上面即为新增,读取,更新,删除,分派。我将这些权力分级,例如:

    

权力等级 含义
0 没有权限
10 自己可操作
30 同一个组织可操作
50 所有可操作

    如果我录入了一条权限数据为,假设role_id为1是普通员工权限,entity_id为1为订单实体

id role_id entity_id can_add can_read can_update can_del can_assign
1 1 1 0 50 30 10 0

    那么这条数据就可以解释成,普通员工权限他对于订单这个实体,没有权限增加订单,可以读取所有订单,可以对跟这个员工同一组织下维护的订单进行更新,可以删除自己创建的订单,并且这个订单他没有权限分派给别人。

    针对如果一个用户有多个角色,那么我们取所有角色对应操作的最大权力作为一个标准,在缓存中维护着这个权限数据,就可以进行权限管控了。

    这里我的权力值使用的是0、10、30、50,这其中其实留了后门,如果我想插入一个权力值位于自己和同一组织之间,例如这个组织下又新建了多个小组,那么我可以使用15作为权力值,这么做是留着用于权力的扩展。

    5、但是,总有操作事先没有考虑到的情况或者一些特殊情况,例如小张在不拥有管理员权限的情况下,拥有管理员的某项权力,我们不可能为了一个人去开一个角色吧,没关系,用一个特殊权限表记录即可。

    

    alias就是上面的can_read,can_update这些字段,level就是10、30、50这些权力值,entity_id则为实体id,现在估计看明白了,RPE表和这个表的合集不就可以满足上面的需求嘛。

    当然,如果你想要这个特殊权限也是需要配置的,那你为privilege建张表维护即可。

    

    6、看起来整体是这样的

    


    就我暂时使用的情况来说,除了配置起来比较繁琐,暂时还没有不能满足的地方,主要是他可以精确到比较细的粒度,即方便拓展又容易理解,我觉得还不错,个人感觉挺通用的,适合大部分场景,所以拿上来跟大家分享。


    完。

展开阅读全文
打赏
3
8 收藏
分享
加载中
更多评论
打赏
0 评论
8 收藏
3
分享
返回顶部
顶部