管理系统的用户角色权限

目录

RBAC1模型：

RBAC2模型：

RBAC3模型：

RBAC0模型实现

用户、角色、权限表关系的设计(mysql)

业务逻辑思路

---

RBAC0模型：

这是权限最基础也是最核心的模型，它包括用户/角色/权限，其中用户和角色是多对多的关系，角色和权限也是多对多的关系。

用户：是发起操作的主体，按类型分可分为2B和2C用户，可以是后台管理系统的用户，可以是OA系统的内部员工，也可以是面向C端的用户,比如阿里云的用户。

角色：起到了桥梁的作用，连接了用户和权限的关系，每个角色可以关联多个权限，同时一个用户关联多个角色，那么这个用户就有了多个角色的多个权限。有人会问了为什么用户不直接关联权限呢?在用户基数小的系统，比如20个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。但是在实际企业系统中，用户基数比较大，其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给100人甚至更多授权，工作量巨大。这就引入了"角色(Role)"概念，一个角色可以与多个用户关联，管理员只需要把该角色赋予用户，那么用户就有了该角色下的所有权限，这样设计既提升了效率，也有很大的拓展性。

权限：是用户可以访问的资源，包括页面权限，操作权限，数据权限:

• 页面权限: 即用户登录系统可以看到的页面，由菜单来控制，菜单包括一级菜单和二级菜单，只要用户有一级和二级菜单的权限，那么用户就可以访问页面。
• 操作权限: 即页面的功能按钮，包括查看，新增，修改，删除，审核等，用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限，如果是，就可以进行下一步操作，反之提示无权限。有的系统要求"可见即可操作"，意思是如果页面上能够看到操作按钮，那么用户就可以操作，要实现此需求，这里就需要前端来配合，前端开发把用户的权限信息缓存，在页面判断用户是否包含此权限，如果有，就显示该按钮，如果没有，就隐藏该按钮。某种程度上提升了用户体验，但是在实际场景可自行选择是否需要这样做。
• 数据权限: 数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只看采购部的数据，在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据，上海用户只能看到上海的数据，解决方案一般是把数据和具体的组织架构关联起来，举个例子，再给用户授权的时候，用户选择某个角色同时绑定组织如财务部或者合肥分公司，那么该用户就有了该角色下财务部或合肥分公司下的的数据权限。

以上是RBAC的核心设计及模型分析，此模型也叫做RBAC0，而基于核心概念之上，RBAC还提供了扩展模式。包括RBAC1，RBAC2，RBAC3模型。

RBAC1模型：

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

RBAC2模型：

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

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

RBAC3模型：

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

RBAC0模型实现

用户、角色、权限表关系的设计(mysql)

1.用户表（t_user）

2.角色表（t_role）

3.权限表（t_permission）

4、用户角色关系表（t_user_role）

5、角色权限关系表(t_role_permission)

业务逻辑思路

1.先完成用户登录的功能，达到登录功能的需求。

2.用户完成登录后读到用户角色(一个或者多个)。

3.看角色里面有权限(一个或者多个)。

3.读取到的权限内容对照成菜单表。

4.把菜单数据返回给前段转换为html内容显示。