Authorization Patterns Cheat Sheet / 授权模式速查表

Introduction / 介绍

Authorization patterns determine where an application decides and enforces access. A Policy Enforcement Point (PEP) protects an operation; a Policy Decision Point (PDP) evaluates the applicable policy. OpenID AuthZEN defines an interface between these components. Use the Authorization Cheat Sheet for baseline controls and Identity Propagation Patterns for trustworthy caller context.

授权模式决定了应用程序在哪里决定和执行访问。一个 策略执行点 (PEP) 保护操作；一个 策略决策点 (PDP) 评估适用的策略。OpenID AuthZEN 定义了这些组件之间的接口。使用 授权速查表 进行基线控制，以及 身份传播模式 进行可信调用者上下文。

In the diagrams, a Policy Administration Point (PAP) manages rules and a Policy Information Point (PIP) supplies attributes used to evaluate them.

在图中，一个 策略管理点 (PAP) 管理规则，一个 策略信息点 (PIP) 提供用于评估它们的属性。

Service-Level Authorization / 服务级授权

Keep enforcement close to the protected resource so it can check the requested action, object, and tenant. Deny by default and validate permissions on every request. Separating policy evaluation from enforcement does not transfer the PEP's responsibility to enforce the result; the AuthZEN trust model explicitly relies on that responsibility.

将执行操作靠近受保护的资源，以便它可以检查请求的操作、对象和租户。默认拒绝，并在每个请求上 验证权限。将策略评估与执行分离并不会将 PEP 执行结果的职责转移；AuthZEN 信任模型 明确依赖于这一职责。

Policies in Application Code / 应用代码中的策略

The service implements both decision and enforcement logic, using a framework's authorization facilities where possible.

服务实现决策和执行逻辑，尽可能使用框架的授权功能。

This can suit a small application with a limited policy surface. Centralize checks within the application's authorization layer and test every protected entry point. Scattered conditional checks make omissions and inconsistent policies harder to detect; changing these rules requires deploying application code. Code-based policies are not inherently fail-open.

这适用于具有有限策略表面的小型应用程序。在应用程序的授权层中集中检查，并测试每个受保护入口点。分散的条件检查使得遗漏和不一致的政策更难检测；更改这些规则需要部署应用程序代码。基于代码的策略并非固有不安全。

Separately Managed Policies / 独立管理策略

The service remains the PEP but asks a PDP to evaluate policies managed independently of business code. The PDP may be embedded, local, or remote; central policy ownership does not require a single central runtime.

服务仍然是PEP，但请求PDP评估独立于业务代码管理的策略。PDP可以是内嵌的、本地的或远程的；中央策略所有权不需要单个中央运行时。

Use this separation when several services need consistent rules and a shared review process. Supply authenticated subject context and authoritative resource attributes, enforce the returned decision before accessing the resource, and deny the operation if no valid decision is available. See Policy and Data Distribution for keeping inputs current and Decisions and Output Handling for enforcing results.

当多个服务需要一致的规则和共享的审查流程时，使用这种分离。提供经过身份验证的主题上下文和权威资源属性，在访问资源之前执行返回的决定，如果不可用有效决定，则拒绝操作。有关保持输入最新，请参阅策略和数据分发，有关执行结果，请参阅决策和输出处理。

Gateway and Proxy Enforcement / 网关和代理执行

A gateway can enforce coarse access rules before forwarding a request. A service-local proxy can perform similar checks on calls to one service. Envoy's external authorization filter illustrates delegation to a PDP and documents how routing changes after authorization can invalidate an earlier check.

网关可以在转发请求之前执行粗粒度的访问规则。服务本地的代理可以对服务调用执行类似的检查。Envoy的外部授权过滤器说明了将任务委托给PDP，并记录了授权后的路由更改如何使早期检查无效。

Treat complete traffic coverage as a deployment requirement, not an automatic property of a gateway. Authenticate permitted callers, restrict direct access to services, and cover internal calls and alternate endpoints. Keep object-level and business-specific checks in the service when the proxy lacks the necessary context. Reevaluate authorization if the effective resource or action changes after a check.

将完整的流量覆盖视为部署要求，而不是网关的自动属性。验证允许的调用者，限制对服务的直接访问，并覆盖内部调用和备用端点。当代理缺乏必要的上下文时，在服务中保留对象级和业务特定的检查。如果检查后的有效资源或操作发生变化，则重新评估授权。

Propagating an Authorization Context / 传播授权上下文

A gateway may attach signed context describing an authenticated subject or an authorization decision for downstream use.

网关可以附加签名上下文，描述已认证的主题或授权决策，以供下游使用。

Downstream services must validate the trusted issuer, integrity, audience, expiry, and the context's applicability to the actual request. Reject direct calls that lack the required context. Strip client-supplied copies of trusted headers before populating them. A signature alone neither prevents bypass nor authorizes a different resource, tenant, or action; follow the JWT validation guidance and retain service-level enforcement.

下游服务必须验证受信任的发行者、完整性、受众、过期时间和上下文对实际请求的适用性。拒绝缺少所需上下文的直接调用。在填充之前移除客户端提供的受信任头部的副本。仅凭签名既不能防止绕过也不能授权不同的资源、租户或操作；遵循JWT验证指南并保留服务级别的执行。

PDP Deployment and Failure Behavior / PDP部署和故障行为

Choose deployment independently of the access control model. For example, OPA supports HTTP, library, and WebAssembly integration; a product name does not imply one deployment mode or a particular access control standard.

独立于访问控制模型选择部署。例如，OPA支持HTTP、库和WebAssembly集成；产品名称并不暗示一种部署模式或特定的访问控制标准。

Deployment / 部署	Security benefit / 安全优势	Required control / 必需的控制
Embedded library 嵌入式库	Evaluation can continue without a remote PDP connection 评估可以在没有远程PDP连接的情况下继续	Keep policy and data current; verify enforcement on every entry point 保持策略和数据最新；在每个入口点验证执行情况
Local sidecar or daemon 本地侧车或守护进程	Shared decision implementation near the service 靠近服务的共享决策实现	Restrict its API and handle process failure; locality alone does not establish trust 限制其API并处理进程故障；仅本地性不足以建立信任
Remote service 远程服务	Shared evaluation and centralized policy administration 共享评估和集中式策略管理	Authenticate and authorize PEPs, protect responses, and deny when a valid decision is unavailable 验证并授权 PEPs，保护响应，并在有效决策不可用时拒绝

All modes depend on the policy and data they use. A local PDP with stale revocation data can still permit access incorrectly. Log the decision and its enforcement, with enough policy/version context to investigate discrepancies and without exposing sensitive attributes.

所有模式都依赖于它们使用的策略和数据。具有过时撤销数据的本地PDP仍然可能错误地允许访问。记录决策及其执行情况，包括足够的策略/版本上下文以调查差异，同时不泄露敏感属性。

Configure PDP errors and timeouts to deny protected operations. Envoy's failure-mode setting makes this choice explicit: allowing requests when authorization fails bypasses the control. A previously loaded policy may continue to be evaluated only within the freshness requirements described in Policy and Data Distribution.

配置PDP错误和超时以拒绝受保护的操作。Envoy的故障模式设置使此选择明确：在授权失败时允许请求绕过控制。先前加载的策略可能仅在新鲜度要求描述的策略和数据分发范围内继续评估。

Prefer service-level enforcement with shared, separately reviewed policies as the system grows. Add gateway checks for early rejection and traffic control; verify that protected operations remain covered when a gateway, policy source, or PDP is unavailable.

随着系统的发展，优先使用服务级别的执行，共享并分别审查的策略。添加网关检查以进行早期拒绝和流量控制；验证在网关、策略源或PDP不可用时受保护的操作仍然得到覆盖。

References / 参考

• OpenID AuthZEN Authorization API 1.0) （OpenID AuthZEN 授权 API 1.0）
• OPA integration documentation) （OPA集成文档）
• Envoy external authorization security considerations) （Envoy外部授权安全考虑）