Ory Keto权限模型问题：管理者无法查看下属资源

一、OPL授权模型常见问题 #

你的核心需求是让管理者通过下属的资源所有者身份继承权限，如果权限检查失败，首先排查模型是否正确定义了权限继承逻辑：

错误模型示例（无继承逻辑） #

如果你的模型只定义了资源的view权限关联直接所有者，未关联所有者的管理者，会直接导致权限拒绝：

namespace default

resource resource {
  relation owner: user
  permission view = owner // 仅允许直接所有者，未配置管理者继承
}

user user {
  relation manager: user
}

正确模型示例（包含层级继承） #

需要在资源的view权限中，通过owner->manager语法实现管理者对下属资源权限的继承：

namespace default

// 用户层级关系定义
user user {
  relation manager: user
}

// 资源权限定义，允许所有者及所有者的管理者查看
resource resource {
  relation owner: user
  permission view = owner or owner->manager
}

二、关系元组配置验证 #

确保你的关系元组完全匹配模型规则：

• user1是resource1的所有者：namespace:default, object:resource1, relation:owner, subject:user1
• user2是user1的管理者：namespace:default, object:user1, relation:manager, subject:user2

此场景下无需强制使用主体集格式，直接关联用户主体即可满足需求。

三、调试步骤 #

1. 用Expand API追溯权限链路
   调用Keto的Check API时开启expand参数，查看权限验证的完整路径，确认是否存在链路断裂：

curl -X POST http://your-keto-host:4466/check \
  -H "Content-Type: application/json" \
  -d '{
    "namespace": "default",
    "object": "resource1",
    "permission": "view",
    "subject": "user2",
    "expand": true
  }'

检查返回结果的allowed字段，以及tree节点是否包含user2 -> user1 (manager) -> resource1 (owner)的完整权限链路。

2. 验证模型语法与命名一致性

• 确保模型中所有关系、权限的命名与元组中的namespace、object、relation完全匹配（Keto对命名大小写敏感）；
• 通过Keto的/validate-model端点验证模型语法合法性，排查潜在语法错误。

3. 分步验证权限链
   拆分验证权限继承的每一环：

• 先确认user1是否能正常获取resource1的view权限；
• 再验证user2是否能通过owner->manager的继承规则获得权限，可直接检查user2是否属于resource1的owner->manager主体集。

内容的提问来源于stack exchange，提问作者z64