SRBAC基于服务和角色的访问控制

SRBAC 是一个基于服务和角色的访问控制，核心：网关、服务、用户、角色、权限、访问控制。

要解决什么问题？

• 我们公司有多套系统，例如 OA 系统、商品管理、订单管理、财务系统、仓库物流系统等等，如何实现跨系统的角色权限分配呢？是否会导致角色权限管理混乱？权限规则设计不统一？
• 多套系统需要各自实现角色权限的验证？同样的逻辑重复造轮子？多套系统如何共同维护用户登录状态？

对于这些问题，或与各个公司都有一套自己的解决方案，但是，你应该试试把这些问题都交给 SRBAC 和 APISIX（网关），SRBAC 实现集中的、跨系统的角色权限管理和分配，SRBAC 提供的 APISIX 插件实现高性能的网关鉴权。

SRBAC 可以让你从多个系统的角色权限管理和鉴权中解脱出来，完全解耦鉴权和业务逻辑，让开发者专注实现业务逻辑，而无需为权限问题分心，提高开发效率，并且给权限管理者提供集中的角色权限管理和分配功能。

SRBAC 亮点

• 适用于多服务集群
• 适用于微服务网关
• 实现对于服务和接口的访问控制
• 实现跨服务的角色权限控制
• 实现访问控制和业务代码完全解耦，业务代码只需关注业务，无需为权限控制重复造轮子

SRBAC 权限节点类型

• 接口权限节点：是否有权限请求某些接口
• 数据权限节点：是否同一个接口不同角色权限的用户请求获取到不同的数据，或执行不同的逻辑
• 菜单权限节点：是否有权限显示某些菜单或按钮

网关鉴权

• 当网关判断到接口允许匿名访问时，直接将请求代理到该服务
• 当网关判断到用户没有登录时，直接响应：401 未登录
• 当网关判断到用户没有接口权限时，直接响应：403 没有权限
• 当网关判断到用户有接口权限时，在请求头中携带该用户拥有的该服务的数据权限，再将请求代理到该服务

内容管理

• 服务管理
  • 每个服务必须有一个唯一标识
  • 服务的增删改查
• 用户管理
  • 每个用户必须有一个唯一 id
  • 用户的增删改查
• 角色管理
  • 角色的增删改查
  • 配置一个角色拥有哪些服务的权限
• 权限节点管理
  • 基于服务管理权限节点，即所有权限节点是挂在具体的服务下面的
  • 菜单权限节点的增删改查
  • 接口权限节点的增删改查
  • 数据权限节点的增删改查
• 角色权限分配
  • 给角色分配具体服务下面的菜单权限节点
  • 给角色分配具体服务下面的接口权限节点
  • 给角色分配具体服务下面的数据权限节点
• 用户角色权限分配
  • 给用户分配角色
  • 给用户分配菜单权限节点
  • 给用户分配接口权限节点
  • 给用户分配数据权限节点
  • 用户的最终权限是所分配的角色和直接分配的权限节点的并集

APISIX 插件

• rbac-access
  • 动态鉴权的核心插件，实现基于 SRBAC 模型的动态鉴权
• static-jwt-auth
  • 相对于 APISIX 官方插件 jwt-auth 而言更轻量级的插件，它无需添加 consumer 既可以实现 auth 相关功能
• token-auth
  • 相对于 APISIX 官方插件 key-auth 而言更轻量级、扩展性更强的插件，依托 Redis 可以完成用户相关的更多的操作：可以动态维护用户状态、用户状态自动过期、APISIX 多节点集群数据共享
• business-upstream
  • 企业动态路由插件，适用于 SaaS 企业平台，根据企业的付费等级动态路由，达到不同企业等级之间物理隔离的目的

业务流程

界面截图