普通的系统无非 CRUD，那系统如何控制一个用户该看到哪些数据、能操作哪些功能？日常开发中最常用到 RBAC 和 OAuth2 这两种访问控制和授权方案

RBAC 基于角色的访问控制

所有的访问控制模型，实质上都是在解决同一个问题：“谁（User）拥有什么权限（Authority）去操作（Operation）哪些资源（Resource）”

处理这个问题其实并不困难，只需要在每个用户进行操作的时候去判断一下他是否有该操作的权限即可，简单来说，在用户访问接口的时候去判断一下该用户的权限，权限不足则拒绝他

这么做虽然简单，但是会面临一个问题，一但系统的功能变的丰富，需要判断的接口、每个接口进行的判断也会成指数倍增加。这么做肯定是不会被接受的，我们需要一种解耦手段

RBAC 将权限从用户身上剥离，改为绑定到角色（Role）上，将权限控制变为对角色拥有操作哪些资源的许可

角色拥有许可，许可是抽象权限的具象化体现，权限在 RBAC 系统中的含义是允许何种操作作用于哪些资源之上，这句话的具体实例即为许可

提出许可这个概念的目的其实与提出角色的目的是完全一致的，只是更为抽象。角色为的是解耦用户与权限之间的多对多关系，而许可为的是解耦操作与资源之间的多对多关系，譬如不同的数据都能够有增、删、改等操作，如果将数据与操作搅和在一起也会面临配置膨胀问题

很多系统借鉴了 RBAC 的思想，提取用户为角色，用角色来管理用户，用许可来管理订单。上面的描述可能有些抽象，举个例子：

在这个页面中，每个模块都可以被视为一种许可。只有有对应许可的角色可以看见这个模块，比如有一个角色被称为创作人，该角色有内容管理、评论管理的权限，用户就可以看见内容管理和评论管理模块

RABC 至少需要5张表：

• 用户表 (User)
• 角色表 (Role)
• 权限表 (Permission)
• 用户-角色关系表 (User_Role)
• 角色-权限关系表 (Role_Permission)

以下是一段 RBAC 的代码

    @Override
    public List<Operation> buildOperationList(SalesClue salesClue, CrmUserRoleEnum userRoleEnum) {
        List<Operation> ret = Lists.newArrayList();

        ClueStatusEnum status = salesClue.getStatus();
        SaleProgressEnum saleProgress = salesClue.getSaleProgress();
        if (status == ClueStatusEnum.PENDING_FOLLOW_UP
                || status == ClueStatusEnum.IN_PROGRESS
                || status == ClueStatusEnum.ON_HOLD
                || (status == ClueStatusEnum.CLOSED && !Objects.equals(saleProgress, SaleProgressEnum.PAYMENT_COMPLETED))) {

            ret.add(Operation.builder()
                    .name(OPERATION_TRANSFER)
                    .type(Operation.TRANSFER)
                    .order(1)
                    .build());

            ret.add(Operation.builder()
                    .name(OPERATION_CONTACT_CONSUMER)
                    .url(CLUE_DETAIL_URL + IDEncoder.encode(salesClue.getId()))
                    .type(Operation.TYPE_FORWARD)
                    .order(2)
                    .build());
        } else if (status == ClueStatusEnum.PENDING_CLAIM) {
            if (userRoleEnum == CrmUserRoleEnum.TEAM_LEADER || userRoleEnum == CrmUserRoleEnum.MANAGE) {
                ret.add(Operation.builder()
                        .name(OPERATION_ALLOCATION_SALES)
                        .type(Operation.TYPE_ALLOCATION_SALES)
                        .order(1)
                        .build());
            }
            ret.add(Operation.builder()
                    .name(OPERATION_CLAIM)
                    .type(Operation.CLAIM_CLUE)
                    .order(1)
                    .build());
        } else if (status == ClueStatusEnum.WAIT_FOR_ALLOCATION) {
            if (userRoleEnum == CrmUserRoleEnum.TEAM_LEADER || userRoleEnum == CrmUserRoleEnum.MANAGE) {
                ret.add(Operation.builder()
                        .name(OPERATION_ALLOCATION_SALES)
                        .type(Operation.TYPE_ALLOCATION_SALES)
                        .order(1)
                        .build());
            }
        }

        return ret;
    }

ABAC 基于属性的访问控制

基于属性的访问控制（Attribute-Based Access Control，简称 ABAC） 是一种比 RBAC 模型更加灵活的授权模型，它的原理是通过各种属性来动态判断一个操作是否可以被允许。这个模型在云系统中使用的比较多，比如 AWS，阿里云等

在 ABAC模型中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的

• 对象：对象是当前请求访问资源的用户。用户的属性包括 ID，个人资源，角色，部门和组织成员身份等
• 资源：资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至 API
• 操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”
• 环境：环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等

在 ABAC 模型的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC 模型决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过

当你发现权限规则频繁变动、if-else 无限膨胀、需要引入更多动态判断维度（如时间、地点、数据归属）时，就是引入 ABAC 设计思想的好时机

举个例子，下面是一个超级简单的 ABAC 实现，该方法根据 salesClue 中的状态以及用户的 role 来分装操作项：

PERMIT (user, action, salesClue)
IF
    salesClue.status IN ['PENDING_FOLLOW_UP', 'IN_PROGRESS', 'ON_HOLD']
        OR (salesClue.status == 'CLOSED' AND salesClue.saleProgress != 'PAYMENT_COMPLETED')
    AND action.name IN ['OPERATION_TRANSFER', 'OPERATION_CONTACT_CONSUMER']