基于角色的访问控制的权限系统设计

最新推荐文章于 2024-07-24 08:36:41 发布

原创最新推荐文章于 2024-07-24 08:36:41 发布 · 928 阅读

2 ·

CC 4.0 BY-SA版权

思路分享专栏收录该内容

3 篇文章

订阅专栏

基于角色的访问控制(Role-Based Access Control,RBAC)

在这里插入图片描述

权限

权限是用户可以访问的资源, 包括页面权限、操作权限、数据权限。

页面权限

即用户登录系统可以看到的页面, 由菜单来控制, 菜单包括一级菜单和二级菜单, 只要用户有一级和二级菜单的权限, 那么用户就可以访问页面

操作权限

即页面的功能按钮，包括查看, 新增, 修改, 删除, 审核等，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限。如果是, 就可以进行下一步操作, 反之提示无权限。
有的系统要求 “可见即可操作”, 意思是如果页面上能够看到操作按钮, 那么用户就可以操作, 要实现此需求, 这里就需要前端来配合, 前端开发把用户的权限信息缓存, 在页面判断用户是否包含此权限, 如果有, 就显示该按钮, 如果没有, 就隐藏该按钮。
某种程度上提升了用户体验, 但是在实际场景可自行选择是否需要这样做

数据权限

数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只看采购部的数据。
在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据，上海用户只能看到上海的数据，解决方案一般是把数据和具体的组织架构关联起来。
举个例子, 再给用户授权的时候, 用户选择某个角色同时绑定组织如财务部或者合肥分公司, 那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。

RBAC1 模型

RBAC1 模型引入了角色继承 (Hierarchical Role) 概念，即角色具有上下级的关系，角色间的继承关系可分为一般继承关系和受限继承关系。
一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。
而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

RBAC2 模型

基于核心模型的基础上，进行了角色的约束控制，RBAC2 模型中添加了责任分离关系。其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。主要包括以下约束:

互斥角色:
同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。
（互斥角色是指各自权限互相制约的两个角色。比如财务部有会计和审核员两个角色, 他们是互斥角色, 那么用户不能同时拥有这两个角色, 体现了职责分离原则）
基数约束:
一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配
先决条件角色:
即用户想获得某上级角色, 必须先获得其下一级的角色

RBAC3 模型

即最全面的权限管理, 它是基于 RBAC0，将 RBAC1 和 RBAC2 进行了整合。

用户组

当平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的所有员工，如果直接给用户分配角色，管理员的工作量就会很大。
如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有该角色，以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。
根据用户组是否有上下级关系, 可以分为有上下级的用户组和普通用户组。

具有上下级关系的用户组

最典型的例子就是部门和职位，可能多数人没有把部门职位和用户组关联起来吧。
当然用户组是可以拓展的，部门和职位常用于内部的管理系统，如果是面向 C 端的系统。
比如淘宝网的商家，商家自身也有一套组织架构，比如采购部，销售部，客服部，后勤部等，有些人拥有客服权限，有些人拥有上架权限等等，所以用户组是可以拓展的