21 December, 2024

AuthZen 工作组：打造统一的授权模型交互标准

笔记

背景

随着技术的快速发展并日益复杂化，安全和合规性的要求不断提升，传统的授权方案已经难以满足企业不断变化的需求。授权系统面临着如下挑战：

动态和细粒度的授权需求增加：现代应用和服务需要能够对用户权限进行实时的管理，以适应快速变化的业务需求和复杂的数据访问控制规则。传统的授权模式，如将权限直接嵌入到令牌中的 OAuth2，往往灵活度不足。
缺乏互操作性和标准化：随着业务和组织架构的复杂化，企业慢慢地会采用不同的授权解决方案，而且这些方案中往往因为缺乏同一的交互模型和协议，无法在不同系统、应用和服务之间进行无缝集成和安全交互，阻碍了技术创新以及现有架构的融合。
安全性和合规性要求提高，随着数据保护法规和行业合规标准的不断增强，组织需要更加精确和可控的授权机制来保护敏感数据。

这些促使授权系统需要持续演进以适应新的技术和业务需求，通过标准化机制、协议和格式来交换授权相关信息，促进向更动态、更细粒度的授权能力的范式转变。

如此就有了 OpenID 基金会的 AuthZen 工作组。

AuthZen 工作组

AuthZen 是 Authorization Exchange 的简称（起初看到这个名字我以为 Zen 就是那个 Zen），是 OpenID 基金会比较新的工作组，官宣于 2023 年 10 月。

AuthZEN 工作组的目的是提供标准机制、协议和格式，以便在一个组织内部或跨组织之间的组件传递授权相关信息，这些组件可能由不同实体开发或来源。

正如起名字，这个工作组试图来解决在授权中遇到的 Exchange（交换）问题，即如何在不同组件之间交换授权信息。

让我们来看一下 Exchange 发生在哪些地方：

XACML 授权模型

下面是源于 23 年前的 XACML 数据流模型。

XACML 是一个授权标准，定义了一种策略语言，用于描述授权策略和一种请求/响应协议，用于在授权请求者和授权决策者之间传递授权请求和决策。

XACML 主要是一个基础属性的访问控制模型，属性作为决策是否授权访问的输入，要采用的访问控制策略作为规则（每条规则都包含一系列的条件，这些条件决定请求是否被批准），策略执行的结果作为输出。

图片来自维基百科

XACML 将访问控制分离为多个组件：PEP、PDP、PAP 和 PIP ，这些组件组成完整的授权系统。

PEP（Policy Enforcement Point）：策略执行点，负责对请求进行拦截和检查，以确定是否允许访问。每个使用访问控制的环境都有一个 PEP。
PDP（Policy Decision Point）：策略决策点，负责根据策略和请求的属性来做出访问决策。决策点通常独立于使用访问控制的环境。
PIP（Policy Information Point）：策略信息点，负责提供 PDP 所需的策略信息。信息点充当对执行点输入属性的扩充。
PAP（Policy Administration Point）：策略管理点，负责管理策略。

大体的流程如下：

用户发起请求要访问某个资源，请求被 PEP 拦截。
PEP 将请求转换为 XACML 授权请求，发送给 PDP。
PDP 根据请求的属性和配置的策略（由 PAP 管理）决策是否允许访问。
如果需要，PDP 还会通过 PIP 获取额外的属性用于执行策略。
PDP 返回决策结果给 PEP。
PEP 根据 PDP 的决策，决定是否允许访问。

在实际的应用中，策略的执行点会根据不同的场景和需求进行不同粒度的定制。例如，在请求的入口处（网关）进行拦截，在应用的内部各个 API 端点进行拦截。

根据耦合性的要求，PEP 的角色可以是一个边车、一个 SDK 或者一个库。

AuthZen 的首要目标

在多厂商、多技术生态共存的场景中，PEP 和 PDP 之间的互操作性问题是一个常见的挑战。AuthZen 将解决 PEP 和 PDP 之间的互操作性问题作为其首要目标。

互作操作性代表了组件 PEP 和 PDP 间的协作能力，它允许异构组件之间的协作，无需关心组件使用的技术、编程语言或者协议。API 是实现互操作性的桥梁，也是重要的实现方式之一，通过定义明确的接口规范，允许不同组件通过标准化的请求和响应进行通信，隐藏了底层复杂的实现细节。

为此，AuthZen 工作组将制定一套标准化的 API 规范

Authorization API

Authorization API 1.0（目前这个 API 还是处于草案阶段），用于支持 PEP 和 PDP 之间的通信，以实现二者之间的互操作性。简单来说，Authorization API 由 PDP 实现并提供给 PEP 来调用：PDP 是决策服务的提供者，PEP 是决策服务的调用者。

版本

Authorization API 当前的版本是 1.0，对应 API 的路径是 /v1/。可以通过额外的 API 方法、参数或者头部来对 API 进行扩展。

信息模型

截止目前，Authorization API 定义了如下的信息模型：

Subject 主体：代表调用 API 的实体，可以是用户、设备或者服务。
Resource 资源：代表访问请求的目标，可以是文件、数据库、API 等。
Action 操作：代表主体对资源的操作，可以是读、写、删除等。常见的操作有 can_access、can_create、can_read、can_update、can_delete。
Context 上下文：代表访问请求相关的环境或者上下文数据，可以是时间、地点、设备、网络等。

评估请求

在 Authorization API 请求中，subject、action、resource 是必需字段，context 是可选字段。

示例：

{
  "subject": {
    "type": "user",
    "id": "alice@acmecorp.com",
    "properties": {
      "department": "Sales",
      "ip_address": "172.217.22.14",
      "device_id": "8:65:ee:17:7e:0b"
    }
  },
  "resource": {
    "type": "book",
    "id": "123",
    "properties": {
      "library_record":{
        "title": "AuthZEN in Action",
        "isbn": "978-0593383322"
      }
    }
  },
  "action": {
    "name": "can_read",
    "properties": {
      "method": "GET"
    }
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}

评估响应

评估的响应非常简单，只包含了一个布尔类型的字段 decision，可选值只有 true 和 false，代表允许请求和拒绝请求。

响应中还可以提供一个可选的 context 字段，用于向 PEP 传达可以使用的附加信息，比如授权失败的原因等。该字段可以是任何 JSON 对象。

示例：

{
  "decision": true,
  "context": {
    "id": "0",
    "reason_admin": {
      "en": "Request failed policy C076E82F"
    },
    "reason_user": {
      "en-403": "Insufficient privileges. Contact your administrator",
      "es-403": "Privilegios insuficientes. Póngase en contacto con su administrador"
    }
  }
}