ory/keto是否支持上下文与基于时间的授权？含IP访问控制场景咨询

Ory Keto基于Zanzibar模型，核心聚焦静态关系型授权，本身不原生支持动态上下文（如IP、时间）的直接检查，但可以通过以下两种方案实现你的需求：

方案1：将上下文属性转化为临时关系（适合简单场景） #

把用户的动态上下文（如当前IP所属范围、当前时间窗口）映射为Keto中的临时关系，授权检查时验证这些关系与基础文档权限的交集。

实现步骤： #

1. 定义命名空间
   创建ip_range、time_window及关联的文档命名空间：

   // ip_range 命名空间：管理IP范围与用户的关联
   {
     "id": "ip_range",
     "relations": {
       "includes_user": {
         "rewrite": { "union": [{ "this": {} }] }
       }
     }
   }
   
   // time_window 命名空间：管理时间窗口与用户的关联
   {
     "id": "time_window",
     "relations": {
       "active_for_user": {
         "rewrite": { "union": [{ "this": {} }] }
       }
     }
   }
   
   // document 命名空间：要求同时满足文档权限、IP范围、时间窗口
   {
     "id": "document",
     "relations": {
       "view": {
         "rewrite": {
           "intersection": [
             { "namespace": "user", "object": "{user_id}", "relation": "can_view" },
             { "namespace": "ip_range", "object": "{allowed_ip}", "relation": "includes_user" },
             { "namespace": "time_window", "object": "{allowed_slot}", "relation": "active_for_user" }
           ]
         }
       }
     }
   }
   

2. 动态维护临时关系

   • 用户发起请求时，先验证IP是否在允许范围，符合则添加关系：ip_range:0.0.0.10/11#includes_user@user:john（可设置TTL自动过期）
   • 验证当前时间是否在允许窗口（如工作日9-18点），符合则添加关系：time_window:work_hours#active_for_user@user:john

3. 授权检查Payload
   调用Keto Check API时，传入上下文参数验证交集权限：

   {
     "namespace": "document",
     "object": "doc_123",
     "relation": "view",
     "subject": "user:john",
     "context": {
       "user_id": "john",
       "allowed_ip": "0.0.0.10/11",
       "allowed_slot": "work_hours"
     }
   }
   

方案2：中间层预处理+Keto基础授权（适合复杂动态场景） #

在Keto前添加中间层（如API网关、自定义服务），先完成上下文验证，再调用Keto检查基础关系权限。

实现步骤： #

1. 中间层上下文验证

   • 提取请求的客户端IP，验证是否在允许范围内
   • 提取当前时间，验证是否在指定时间窗口内
   • 若任一验证不通过，直接返回403；验证通过后再调用Keto

2. Keto基础授权配置
   保持简洁的文档与用户命名空间：

   // document 命名空间
   {
     "id": "document",
     "relations": {
       "view": {
         "rewrite": { "union": [{ "namespace": "user", "object": "{user_id}", "relation": "can_view" }] }
       }
     }
   }
   
   // user 命名空间
   {
     "id": "user",
     "relations": {
       "can_view": { "rewrite": { "union": [{ "this": {} }] } }
     }
   }
   

3. 完整授权流程

   1. 用户请求访问文档 → 中间层检查IP和时间 → 验证通过
   2. 中间层调用Keto Check API：

      {
        "namespace": "document",
        "object": "doc_123",
        "relation": "view",
        "subject": "user:john"
      }
      

   3. 若Keto返回allowed: true，则允许访问；否则返回403

注意事项 #

• 方案1的临时关系需设置合理TTL，避免数据堆积，可利用Keto的关系过期特性自动清理
• 方案2需确保中间层是请求的唯一入口，防止绕过上下文验证直接调用Keto

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