SRBAC
基于服务和角色的访问控制,核心:网关、服务、用户、角色、权限、访问控制。
要解决什么问题?
- 我们公司有多套系统,例如 OA 系统、商品管理、订单管理、财务系统、仓库物流系统等等,如何实现跨系统的角色权限分配呢?是否会导致角色权限管理混乱?权限规则设计不统一?
- 多套系统需要各自实现角色权限的验证?同样的逻辑重复造轮子?多套系统如何共同维护用户登录状态?
对于这些问题,或许各个公司都有一套自己的解决方案,但是,你应该试试把这些问题都交给 SRBAC 和 APISIX(网关),SRBAC 实现集中的、跨系统的角色权限管理和分配,SRBAC 提供的 APISIX 插件实现高性能的网关鉴权。
SRBAC 可以让你从多个系统的角色权限管理和鉴权中解脱出来,完全解耦鉴权和业务逻辑,让开发者专注实现业务逻辑,而无需为权限问题分心,提高开发效率,并且给权限管理者提供集中的角色权限管理和分配功能。
SRBAC 亮点
- 适用于多服务集群
- 适用于微服务网关
- 实现对于服务和接口的访问控制
- 实现跨服务的角色权限控制
- 实现访问控制和业务代码完全解耦,业务代码只需关注业务,无需为权限控制重复造轮子
SRBAC 权限节点类型
- 接口权限节点:是否有权限请求某些接口
- 数据权限节点:是否同一个接口不同角色权限的用户请求获取到不同的数据,或执行不同的逻辑
- 菜单权限节点:是否有权限显示某些菜单或按钮
网关鉴权
- 当网关判断到接口允许匿名访问时,直接将请求代理到该服务
- 当网关判断到用户没有登录时,直接响应:401 未登录
- 当网关判断到用户没有接口权限时,直接响应:403 没有权限
- 当网关判断到用户有接口权限时,在请求头中携带该用户拥有的该服务的数据权限,再将请求代理到该服务
内容管理
- 服务管理
- 用户管理
- 角色管理
- 权限节点管理
- 基于服务管理权限节点,即所有权限节点是挂在具体的服务下面的
- 菜单权限节点的增删改查
- 接口权限节点的增删改查
- 数据权限节点的增删改查
- 角色权限分配
- 给角色分配具体服务下面的菜单权限节点
- 给角色分配具体服务下面的接口权限节点
- 给角色分配具体服务下面的数据权限节点
- 用户角色权限分配
- 给用户分配角色
- 给用户分配菜单权限节点
- 给用户分配接口权限节点
- 给用户分配数据权限节点
- 用户的最终权限是所分配的角色和直接分配的权限节点的并集
APISIX 插件
- rbac-access
- 动态鉴权的核心插件,实现基于 SRBAC 模型的动态鉴权
- static-jwt-auth
- 相对于 APISIX 官方插件 jwt-auth 而言更轻量级的插件,它无需添加 consumer 既可以实现 auth 相关功能
- token-auth
- 相对于 APISIX 官方插件 key-auth 而言更轻量级、扩展性更强的插件,依托 Redis 可以完成用户相关的更多的操作:可以动态维护用户状态、用户状态自动过期、APISIX 多节点集群数据共享
- business-upstream
- 企业动态路由插件,适用于 SaaS 企业平台,根据企业的付费等级动态路由,达到不同企业等级之间物理隔离的目的
部署和使用指南
业务流程
这是一个简化的业务流程图,如果整个系统需要有更高的负载能力和可用性,可以选择:
- Redis 采用集群部署(待验证);
- 在用户客户端和 APISIX 之前增加 LB,APISIX 采用多节点部署;
- APISIX 和业务系统之间增加 LB,后端的业务系统按实际情况选择多节点部署;
- APISIX 和业务系统之间也可以换作服务注册发现,能够完成更多服务治理。
界面截图