这里说一个比较常见的RBAC的错误的用法：那就是直接使用角色做权限判断。比如只有角色A才能做文章的删除操作。

function delPost(postId){
    if(!isRole('A')){
        return false;
    }
}

如果需求该为角色B也可以删除文章。那就必须修改代码

function delPost(postId){
    if(!isRole('A')&&!isRole('B')){
        return false;
    }
}

正确的做法应该是添加"删除文章"这个功能，把这个功能关联到相应的角色上。判断的时候是根据功能去判断而不是角色。

function delPost(postId){
    if(!hasPermission('POST_DEL')){
        return false;
    }
}

针对“只有角色A才能做文章的删除操作”这一需求，把这个删除功能关联到角色A上，然后把需要这个操作权限的用户加入到角色A中即可。当别的角色也需要这个操作权限，把功能关联到对应角色上即可，不需要再修改代码。

在RBAC的核心基础上，还可以做相应的扩展，比如角色继承，角色分组之类的，这些扩展都是为了在一定程度简化权限管理工作。

ABAC(Attribute-Based Access Control)(基于属性的权限控制)

RBAC虽然是目前最普遍的权限控制模型。但是某些情况下，RBAC是无法满足并且也实现不了的。比如业务员1和业务员2都属于业务员角色，都有查看客户订单的权限。当有一个需求，要求业务员1只能查看北京地区的客户的订单，业务员2只能查看上海的客户的订单。这单单使用RBAC是无法实现。借助RBAC，可行的做法是，分地区创建角色，然后程序中根据角色做数据的过滤，这种做法缺点之前也提到过，需求变更的时候可能需要每次都修改代码。

上面业务员查看订单的例子，地区是订单的一个属性，需求就是针对这个地区属性来做订单的查询范围的权限控制。这种权限控制方式就是ABAC(Attribute-Based Access Control)(基于属性的权限控制)，也被一些人称为是权限系统设计的未来。

不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性是否满足某种条件来进行授权判断的（可以编写简单的逻辑）。属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。

例如规则：“允许所有班主任在上课时间自由进出校门”这条规则，其中，“班主任”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。

ABAC非常的灵活，但是实现也是非常的难。这其中涉及到逻辑的动态执行，数据动态过滤等，更加具体就是动态拼接SQL语句(使用ORM的话就是动态组装对应ORM的查询语句)。

感兴趣的可以在Github上搜索ABAC，看看不同语言是否已经有现成的解决方案。下面说说我学习到的一种实现方式：

还是业务员查看订单的例子，在RBAC的基础上，扩展一个实体规则，订单就是实体，也就是针对订单设置一系列的规则。规则存储格式可以是json也可以是xml,甚至是Sql语句，能解析即可。比如北京地区这个规则：

{
    "regionId":1
}

上海地区：

{
    "regionId":3
}

regionId 就是系统里对应区域的Id,也是订单或订单相关表的某个字段。

保存这个规则的时候，规则内容(就是上面的json),规则实体(也就是订单，表明这个规则是针对订单的)是必须的。也可以加上这个规则是适用增删改查中的一种或多种。

创建好实体的规则，将规则与角色做关联，也就是将北京地区的规则关联到北京地区角色上，上海地区的规则关联到上海地区角色上。

后端做权限校验的时候，还是先按RBAC模型的控制方式进行校验(是否具备订单查看权限)，然后根据当前操作对象(也就是实体)，取出用户所属角色关联的对应实体的规则。然后解析规则，动态拼接Sql或者ORM语句。

没做地区限制(或没配置规则)的时候，Sql可能是

select userId,orderNo,createdDate from T_Order

配置了规则，解析拼接后可能就是

select userId,orderNo,createdDate from T_Order where regionId=1

这里是针对地区这个属性实现了动态的权限控制。实际开发过程中，要控制的东西是非常多了，查看字段的控制，数据范围的控制。要满足这些复杂的控制，需要制定一套完整的规则，以及针对规则编写相应的解析程序。比如根据配置的规则，最后解析出来可能是各种Sql语句:<,>,=,like,in,not in等等。

可以看出，要真正的落地实现ABAC是多么的复杂。每次都要解析规则，对程序的性能也造成的影响，就算使用缓存，命中的概率也是非常的小，因为很多因素都是动态的。

所以，如果需要根据属性做权限判断的场景不是很多的话，还是建议使用RBAC，然后程序中做判断比较省事省力。

总结

ACL早期定义中是一种权限控制机制，这种机制直接维护的是用户与功能的关系，功能就是针对对象定义的一些操作，比如增删改查的等。用户与功能的关系列表也称为权限列表或访问控制列表，现在说ACL，一般就是指这个权限列表或访问控制列表，但是里面维护的关系不一定是用户与功能的关系，在RBAC中维护的就是角色与功能的关系。

RBAC在ACL的基础上加入了角色的概念，权限列表或访问控制列表里维护的不再是用户与功能的关系，而是角色与功能的关系。ACL可以和RBAC混着用，既可以在角色上设置权限，也可以直接给用户设置权限，更加灵活。借助角色的思想，可以在用户组，组织，职位等等上设置权限，以便更好的做好权限管理，也就是将权限设置从单一个体转移到某一类组合上。

ABAC非常的灵活，也非常的难实现。

参考文章

权限系统设计模型分析

Authorization Models: ACL, DAC, MAC, RBAC, ABAC