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 企业平台，根据企业的付费等级动态路由，达到不同企业等级之间物理隔离的目的
业务流程
界面截图
评论