本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

转载自夜明的孤行灯

本文链接地址: https://www.huangyunkun.com/2018/07/23/access-control-and-role-model/

我们在做任何一款产品的时候，或多或少都会涉及到用户和权限的问题。比如企业软件，不同的部门，不同的岗位都需要不同的权限控制；再比如CMS系统，那也有管理员，内容审核等等；

产品权限控制部分的好坏直接影响了产品的可扩展性和后期维护性，当然市面上也有很多成体系的权限控制方案，比如你可以用Apache Shiro。

这里抛开框架，我们来看看最简单粗暴的方案吧

用户等于权限

简单粗暴并不代表它不能用，比如在一个权限极为简单的系统，假设只是管理员和普通用户，我们完全可以硬编码管理员的用户名在代码中，然后一个if-else就可以解决问题。

当然为了后期的灵活性，而我们管理员又经常改变，那么我们在表中额外加一个字段，通过这个字段来表示用户是否为管理员。

ACL

用户直接关联权限对于大规模的应用比较难维护，而且粒度比较大。ACL可以很好解决粒度问题，因为它对于每一个资源都定义了一个权限控制表，当然灵活性那是很高了，但是维护成本太高，而且大规模使用性能也很难保证。

RBAC0

用户等于权限这种映射和管理太粗旷了，在稍微复杂一点的情况下就很难使用了，比如有两种管理员，权限有大有小，甚至都不是子集关系。
RBAC0就进了一步，将权限和角色捆绑在一起，而用户和角色联系在一起。因为用户和角色是多对多，而角色和权限也是多对多，那么整体来看可以实现的控制灵活性和粒度就非常好了，而用户拥有的权限等于他所有的角色持有权限之和。

这种的好处是权限的聚合，比如抽象出了财务专员和人事专员，那么老板很可能就是单纯拥有这两个角色而已。

RBAC1

在RBAC0的基础上引入分层概念，就是RBAC1了，也就是带继承的模型。比如财务专员和财务负责人，那么财务负责人其实是有财务专员的所有权限的。RBAC1并不是增加了整体的灵活性，但是简化了权限管理。

RBAC2

RBAC2是限制模型，虽然是RBAC2，但是它和RBAC1没啥关系，而是在RBAC0的基础上增加了限制条件。用户的权限取决于它激活的角色所有的权限，同时角色还不能拥有互斥的角色，比如一个人不能又发起合同，又审批合同。
同时RBAC2还要求角色之间是有依赖的，比如要激活财务负责人的角色，必须拥有公司员工这个角色。

当然这些限制有一套专业名词：静态职责分离和动态职责分离

RBAC3

RBAC3是RBAC1和RBAC2的集合，即同时拥有角色分层和限制管理。

ABAC

基于属性的权限验证是比RBAC新一些的概念和模型抽象， 之前说的所有模型都是将用户通过某种方式关联到权限的方式，唯一的不同就是怎么关联的。

而ABAC则是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断。属性通常来说分为四类：用户属性，环境属性，操作属性和对象属性，所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。

当然高度的灵活性就意味者管理上的复杂性，实际上为了达到ABAC的灵活动态，它需要专门的配置和动态引擎来解析处理，具体可以查看XACML。

 

大部分情况下我觉得RBAC簇的抽象就足够了，毕竟大部分产品的权限还是基于社会分工的，也就是职位职务的，其实RBAC的抽象是非常贴近现实的。

本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

转载自夜明的孤行灯

本文链接地址: https://www.huangyunkun.com/2018/07/23/access-control-and-role-model/