Casbin中基于角色的资源访问控制策略设计

在实际开发中，我们经常需要实现基于角色的细粒度访问控制。Casbin作为一款强大的访问控制框架，提供了灵活的策略定义方式。本文将探讨如何设计一个特定场景下的访问控制策略，其中要求用户只能访问与其角色ID相匹配的资源。

场景需求分析

假设我们有一个服务资源访问控制系统，要求：

1. 用户通过角色获得访问权限
2. 角色名称中包含服务ID（如role:svc/111）
3. 用户只能访问与其角色ID相匹配的服务资源（如svc/111）

初始策略设计

开发者最初尝试了以下模型定义：

[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），能够正确匹配
• 但当请求主体是用户（alice）时，匹配失败

原因在于keyGet3(r.sub, p.sub, 'id')中，当r.sub是用户而非角色时，无法正确提取ID参数。

解决方案

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

1. 自动处理角色继承关系
2. 在匹配过程中考虑角色层级
3. 支持从用户主体向上查找匹配的角色

修改后的匹配规则应为：

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

实现原理

keyMatch4函数的工作机制：

1. 当请求主体是用户时，会向上查找其所属角色
2. 自动提取角色名称中的参数（如id）
3. 与资源对象中的参数进行匹配
4. 确保只有参数完全一致时才允许访问

最佳实践建议

1. 对于角色继承的场景，优先使用keyMatch4而非keyMatch3
2. 保持角色命名规范，使用一致的参数格式
3. 在复杂场景中，可以结合自定义函数实现更灵活的匹配逻辑
4. 测试时需覆盖直接角色访问和用户继承访问两种场景

通过这种设计，我们能够实现既安全又灵活的基于角色的资源访问控制，确保用户只能访问与其角色参数相匹配的资源。