1.前言
现在的系统，对于权限来说，都是非常重要的，不同的用户看到的功能不一样，拥有的操作权限也不同。这些都可视为是动态的，那么就不能在代码中固定某些权限，而是需要通过设计动态权限来实现。
目前常用的模型有两种：
1）RBAC模型
基于角色的访问控制（Role-Based Access Control，简称 RBAC），是指通过用户的角色（Role）授权其相关权限，来实现灵活的访问控制。
2）ABAC模型
基于属性的访问控制（Attribute-Based Access Control，简称 ABAC），是一种比 RBAC模型 更加灵活的授权模型，原理是通过各种属性来动态判断一个操作是否可以被允许。
2.RBAC模型
2.1基本说明
对于此模型，如下图：
将菜单权限分配给不同的角色，再将角色分配给用户，可实现拥有相同权限的用户只分配角色即可。通过这种 用户 -> 角色 -> 权限 之间的关系，可基本解决系统中功能权限的分配使用，其中数据库表设计见下一小节。但遇到更为复杂的数据权限时，此方式已无法支撑，需使用ABAC模型。
2.2数据库表设计
声明：系统表以"s_"开头，业务表以"b_"开头，下表只以设计为主进行参考。
E-R图如下：
用户、角色、菜单之间都是多对多的关系，因此需要使用中间表来记录相互之间的对应关系。
对于用户-角色，可在用户中进行角色的分配，也可在角色中反向授权拥有此角色的用户；
对于角色-菜单，可在角色中对其分配所拥有的菜单权限即可；
对于用户-菜单，可在用户中直接分配所需菜单权限。用户若同时分配了角色和菜单权限，那么用户最终所拥有的权限是两者权限的并集。
【1】菜单表（s_menu）
【2】角色表（s_role）
【3】用户表（s_user）
【4】角色菜单关联表（s_role_menu_rela）
【5】用户角色表（s_user_role_rela）
【6】用户菜单表（s_user_menu_rela）
3.ABAC模型
3.1复杂业务场景权限控制
对于复杂的业务场景，权限控制是必须的，但也是尤为复杂的，先看下面几个例子：
1）先有开发部A，下有三个小组，分别是A1、A2、A3；开发部B，下有二个小组，分别是B1、B2。那么A部门经理可查看A1、A2、A3的数据，不能查看B1、B2的数据，要想查看需向B部门经理申请；同时小组A1的成员只能查看A1的数据，不能查看A2、A3的数据，同理要想查看需向A2、A3组长申请。
2）用户只能对2022年3月1日后的订单数据有操作权限，在此之前的订单只有查看权限。
3）早上10:00前禁止A部门的人访问系统，其他部门需正常使用。
4）本月3号，除了杭州以外的同事禁止使用超级管理员登录系统；本月5号，除了上海以外的同事禁止使用超级管理员登录系统；本月15号，除了北京以外的同事禁止使用超级管理员登录系统；下个月1号系统升级完成，所有同事可使用超级管理员登录系统。
以上这些例子，对于功能权限已不再适用，必须使用数据权限进行控制
3.2ABAC原理
在 ABAC模型 中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。
- 对象：对象是当前请求访问资源的用户。用户的属性包括ID，个人资源，角色，部门和组织成员身份等
- 资源：资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至API
- 操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”
- 环境：环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等
在 ABAC模型 的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC模型 决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。
参考：https://juejin.cn/post/7109812135856881694。
标签：ABAC,菜单,角色,模型,系统,用户,设计,权限 From： https://www.cnblogs.com/zys2019/p/16460578.html