如何设计一个权限系统.docxVIP

如何设计一个权限系统 2021-05-21 权限系统设计 前言 权限管理是全部后台系统的都会涉及的一个重要组成部分，次要目的是对不同的人访问资源进行权限的把握，避开因权限把握缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。 1.权限模型 迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问把握（Role-Based Access Control) 1.1 RBAC-0模型 RBAC-0模型 RBAC-0模型是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。 用户 是发起操作的主体,按类型分可分为2B和2C用户,可以是后台管理系统的用户,可以是OA系统的内部员工,也可以是面对C端的用户,比如阿里云的用户。 角色 起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。 有人会问了为什么用户不直接关联权限呢？在用户基数小的系统,比如20个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。 但是在实际企业系统中，用户基数比较大,其中很多人的权限都是一样的，就是个一般访问权限，假如管理员给100人甚至更多授权,工作量巨大。 这就引入了 角色(Role) 概念,一个角色可以与多个用户关联,管理员只需要把该角色赐予用户,那么用户就有了该角色下的全部权限,这样设计既提升了效率,也有很大的拓展性。 权限 是用户可以访问的资源,包括页面权限,操作权限,数据权限: 页面权限: 即用户登录系统可以看到的页面,由菜单来把握,菜单包括一级菜单和二级菜单,只需用户有一级和二级菜单的权限,那么用户就可以访问页面 操作权限: 即页面的功能按钮，包括查看,新增,修改,删除,审核等，用户点击删除按钮时，后台会校验用户角色下的全部权限能否包含该删除权限。假如是,就可以进行下一步操作,反之提示无权限。有的系统要求可见即可操作,意思是假如页面上能够看到操作按钮,那么用户就可以操作,要实现此需求,这里就需要前端来协作,前端开发把用户的权限信息缓存,在页面推断用户能否包含此权限,假如有,就显示该按钮,假如没有,就隐蔽该按钮。某种程度上提升了用户体验,但是在实际场景可自行选择能否需要这样做 数据权限: 数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，选购部只看选购部的数据。在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据，上海用户只能看到上海的数据，处理方案一般是把数据和具体的组织架构关联起来。 举个例子,再给用户授权的时候,用户选择某个角色同时绑定组织如财务部或者合肥分公司,那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。 用户、角色及权限 以上是RBAC的核心设计及模型分析,此模型也叫做RBAC-0,而基于核心概念之上,RBAC还供应了扩展模式。包括RBAC-1,RBAC-2,RBAC-3模型。下面引见这三品种型 1.2 RBAC-1模型 image 此模型引入了角色承继(Hierarchical Role)概念，即角色具有上下级的关系，角色间的承继关系可分为一般承继关系和受限承继关系。 一般承继关系仅要求角色承继关系是一个确定偏序关系，允许角色间的多承继。 而受限承继关系则进一步要求角色承继关系是一个树结构，实现角色间的单承继。这种设计可以给角色分组和分层，肯定程度简化了权限管理工作。 1.3 RBAC-2模型 基于核心模型的基础上，进行了角色的约束把握，RBAC2模型中添加了责任分别关系。 其规定了权限被赐予角色时，或角色被赐予用户时，以及当用户在某一时辰激活一个角色时所应遵照的强制性规章。 责任分别包括静态责任分别和动态责任分别。次要包括以下约束: 互斥角色: 同一用户只能安排到一组互斥角色集合中至少一个角色，支持责任分别的准绳。互斥角色是指各自权限相互制约的两个角色。比如财务部有会计和审核员两个角色,他们是互斥角色,那么用户不能同时拥有这两个角色,体现了职责分别准绳 基数约束: 一个角色被安排的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以把握高级权限在系统中的安排 先决条件角色: 即用户想获得某上级角色,必需先获得其下一级的角色 1.4 RBAC-3模型 即最全面的权限管理,它是基于RBAC-0，将RBAC-1和RBAC-2进行了整合。 1.5 用户组 当平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的全部员工，假如直接给用户安排角色，管理员的工作量就会很大。 假如把相同属性的用户归类到某用户组，那么