授权与访问控制(废弃)
飞布基于RBAC规范,结合GraphQL的注解能力,实现了API的的授权与访问控制。
快速操作
基本设置
根据业务需求添加角色,系统默认内置admin和user角色(请确保必须有1个角色)
切换到“身份鉴权”TAB,在auth目录下选择
mutatingPostAuthentication
文件编写钩子脚本或选择预制脚本,这里设置所有用户拥有
user
权限,启动钩子,详情前往钩子章节
API设置
前往API管理面板,选择需要设置权限的API
在GraphQL编辑区的工具栏中点击“@角色”,选择匹配模式并添加角色,如添加admin角色
在预览页顶部,选择OIDC供应商,点击前往登录
登录后可查看用户信息,可以看到当前登录用户roles字段包含user角色
输入参数,测试接口,发现接口返回401
重复步骤2,添加admin角色
重复步骤6,可以看到接口执行成功
工作原理
RBAC模型
RBAC(Role-Based Access Control)即:基于角色的权限控制。通过角色关联用户,角色关联权限的方式间接赋予用户权限。
从模型中可以看出,我们要实现两个关键工作:
角色绑定权限:快速操作->API设置中介绍了该过程。
用户绑定角色:快速操作->基本设置中介绍了该过程。
因此,在调用API接口时,只需要判断用户是否拥有当前API的权限即可。
角色注入
由于OIDC规范中没有用户角色的相关声明,用户通过OIDC流程登录后,claim中不包含roles字段。而RBAC要求用户绑定角色,通过角色匹配接口权限。
因此,需要有个地方为用户动态注入roles字段,即用户第一次登录时,根据用户ID或email去特定数据源(可能是自有数据库或者其他数据源)查找其关联的角色,并绑定到roles字段上。考虑到灵活扩展,钩子是实现该功能的最佳场所。具体代码,参考 上文。
匹配规则
飞布支持四种匹配模式,我们以集合的概念进行讲解。
首先,需要知道三个集合域:
全部角色:角色管理列表中配置的角色
用户角色:用户拥有的角色,对应mutatingPostAuthentication钩子中为用户设置的角色
API角色:API RBAC指令上所设置的角色
然后,了解四种集合关系:
requireMatchAll:全部匹配,用户角色包含API角色时,可访问
requireMatchAny:任意匹配,用户角色与API角色有交集时,可访问
denyMatchAll:非全部匹配,当任意匹配或互斥匹配时,可访问
denyMatchAny:互斥匹配,用户角色与API角色互斥时,可访问
最后,以全部角色作为全集,结合四种关系,看用户角色和API角色的交并补情况,确定当前用户是否能访问当前API。
下一步
飞布提供了完整的后台管理示例,您可以参考代码实现自己的管理后台。
最后更新于