RBAC学习(三)
常见的权限模型
- ACL（Access Control List）（访问控制列表）
- DAC （Discretionary Access Control） （自主访问控制）
- MAC (Mandatory Access Control) （强制访问控制）
- RBAC (Role-Based Access Control) （基于角色的访问控制）
- ABAC (Attribute-Based Access Control) （基于属性的访问控制）
RBAC缺点
：比如想要为某个用户单独设置某个功能权限，可能需要为这个功能权限单独创建一个角色，然后把特定的用户关联到这个角色上。当想要移除某个用户的特定功能权限的时候，可能需要重新设置角色的功能权限，把特定功能权限从当前角色中移除，建立新的角色并关联特定的功能权限，然后再把新角色与相关的用户做关联(也可以直接在特定功能的程序里校验操作用户)
ABAC
业务员1和业务员2都属于业务员角色，都有查看客户订单的权限。当有一个需求，要求业务员1只能查看北京地区的客户的订单，业务员2只能看上海的客户的订单。单单使用RBAC是无法实现的。
RBAC解决方法：分地区创建角色，比如北京地区业务员、上海地区业务员。
ABAC：通过动态计算一个或一组属性是否满足某种条件来进行授权判断的（可以编写简单的逻辑）。
- 用户属性（如用户年龄）
- 环境属性（如当前时间）
- 操作属性（如读取）
- 对象属性（如一篇文章，又称资源属性）
比如规则："允许所有班主任在上课时间自由进出校门"，
- 班主任：用户的角色数学
- 上课时间：环境属性
- 进出：操作数学
- 校门：对象属性
针对订单设置一系列规则：
{
"regionId":3
}
regionId是区域id(订单或订单相关表的某个字段)，比如上海地区是3，北京是1。
后端做权限校验时，先按RBAC进行校验（是否具备订单查看权限），然后根据当前操作对象，取出用户所属角色关联的对应实体的规则。
实体的规则-规则与角色做关联
select userId,orderNo,createDate from t_order where regionId = 1;
总结
这里是针对地区这个属性实现了动态的权限控制。实际开发过程中，要控制的东西是非常多了，查看字段的控制，数据范围的控制。要满足这些复杂的控制，需要制定一套完整的规则，以及针对规则编写相应的解析程序。比如根据配置的规则，最后解析出来可能是各种Sql语句:<,>,=,like,in,not in等等。
可以看出，要真正的落地实现ABAC是多么的复杂。每次都要解析规则，对程序的性能也造成的影响，就算使用缓存，命中的概率也是非常的小，因为很多因素都是动态的。
所以，如果需要根据属性做权限判断的场景不是很多的话，还是建议使用RBAC，然后程序中做判断比较省事省力。
