Casbin中基于角色的资源访问控制实现方案

在实际开发中，我们经常需要实现基于角色的细粒度访问控制。Casbin作为强大的访问控制框架，提供了灵活的策略定义方式。本文将探讨如何实现"用户通过角色访问对应资源"的场景。

场景需求分析

假设我们有以下业务需求：

1. 定义服务角色格式为role:svc/{id}
2. 该角色只能访问对应ID的服务资源svc/{id}
3. 用户通过被授予角色来获得访问权限

基础模型设计

首先我们定义基础的模型文件：

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, p.sub) && keyGet3(r.obj, p.obj, 'id') == keyGet3(r.sub, p.sub, 'id') && keyMatch3(r.obj, p.obj) && r.act == p.act

遇到的问题

当使用如下策略时：

p, role:svc/{id}, svc/{id}, read
g, alice, role:svc/111

会出现以下情况：

• role:svc/111访问svc/111 → 成功
• 用户alice访问svc/111 → 失败（预期应为成功）

问题原因在于匹配器中的keyGet3(r.sub, p.sub, 'id')，当请求主体是用户而非角色时，无法正确提取ID参数。

解决方案：使用keyMatch4函数

Casbin提供了keyMatch4函数专门解决这类问题。该函数能够：

1. 自动处理角色继承关系
2. 正确提取路径参数
3. 支持多级路径匹配

修改后的匹配器应为：

[matchers]
m = g(r.sub, p.sub) && keyMatch4(r.obj, p.obj) && r.act == p.act

实现原理

keyMatch4的工作原理：

1. 首先检查请求对象与策略对象的路径模式是否匹配
2. 如果主体是角色，直接比较路径参数
3. 如果主体是用户，会向上查找其所属角色，然后比较路径参数
4. 支持*和{}两种通配符

最佳实践建议

1. 对于需要参数匹配的场景，优先考虑keyMatch4而非keyMatch3
2. 角色命名采用type:id的层级结构，便于参数提取
3. 测试时需同时验证直接角色访问和用户继承访问两种情况
4. 在复杂场景中可结合自定义函数实现更灵活的匹配逻辑

通过这种设计，我们可以实现灵活、可扩展的基于角色的访问控制，同时保持策略定义的简洁性。