CRUD那系统如何控制一个用户该看到哪些数据、能操作哪些功能日常开发中最常用到

RBAC

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

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

这么做虽然简单但是会面临一个问题一但系统的功能变的丰富需要判断的接口、每个接口进行的判断也会成指数倍增加。

这么做肯定是不会被接受的我们需要一种解耦手段

RBAC

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

RBAC

系统中的含义是允许何种操作作用于哪些资源之上这句话的具体实例即为许可

提出许可这个概念的目的其实与提出角色的目的是完全一致的只是更为抽象。

角色为的是解耦用户与权限之间的多对多关系而许可为的是解耦操作与资源之间的多对多关系譬如不同的数据都能够有增、删、改等操作如果将数据与操作搅和在一起也会面临配置膨胀问题

RBAC

的思想提取用户为角色用角色来管理用户用许可来管理订单。

上面的描述可能有些抽象举个例子

在这个页面中每个模块都可以被视为一种许可。

只有有对应许可的角色可以看见这个模块比如有一个角色被称为创作人该角色有内容管理、评论管理的权限用户就可以看见内容管理和评论管理模块

ABAC

更加灵活的授权模型它的原理是通过各种属性来动态判断一个操作是否可以被允许。

这个模型在云系统中使用的比较多比如

AWS阿里云等

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

ID个人资源角色部门和组织成员身份等资源资源是当前用户要访问的资产或对象例如文件数据服务器甚至

API操作操作是用户试图对资源进行的操作。

常见的操作包括“读取”“写入”“编辑”“复制”和“删除”环境环境是每个访问请求的上下文。

环境属性包含访问的时间和位置对象的设备通信协议和加密强度等

ABAC

模型的决策语句的执行过程中决策引擎会根据定义好的决策语句结合对象、资源、操作、环境等因素动态计算出决策结果。

每当发生访问请求时ABAC

决策系统都会分析属性值是否与已建立的策略匹配。

如果有匹配的策略访问请求就会被通过

ABAC

Lists.newArrayList();ClueStatusEnum

status

salesClue.getStatus();SaleProgressEnum

saleProgress

ClueStatusEnum.PENDING_FOLLOW_UP||

status

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

{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

ClueStatusEnum.WAIT_FOR_ALLOCATION)

{if

{ret.add(Operation.builder().name(OPERATION_ALLOCATION_SALES).type(Operation.TYPE_ALLOCATION_SALES).order(1).build());}}return

ret;}