本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 实施 PEP
<a name="pep"></a>

政策执行点 (PEP) 负责接收发送到政策决策点 (PDP) 进行评估的授权请求。PEP 可以是应用程序中必须保护数据和资源的任何地方，也可以是应用授权逻辑的地方。 PEPs 与之相比，相对简单 PDPs。PEP 仅负责请求和评估授权决定，不需要任何授权逻辑。 PEPs不同的是 PDPs，它不能集中在 SaaS 应用程序中。这是因为需要在整个应用程序及其接入点中实施授权和访问控制。 PEPs 可以应用于微服务 APIs、前端后端 (BFF) 层或应用程序中需要或需要访问控制的任何点。在应用程序中 PEPs 广泛使用可确保在多个点经常独立地验证授权。   

要实施 PEP，第一步是确定应在应用程序中何处实施访问控制。在决定 PEPs 应在何处集成到应用程序中时，请考虑以下原则： 

*如果应用程序公开了 API，则应对该API进行授权和访问控制。*

这是因为在面向微服务或面向服务的架构中， APIs 用作不同应用程序功能之间的分隔符。将访问控制作为应用程序功能之间的逻辑*检查点*包含在内是有意义的。**我们强烈建议您将访问 SaaS 应用程序中的每个 API PEPs 作为先决条件。**也可以在应用程序的其他位置集成授权。在单片应用程序中，可能需要在应用程序本身的逻辑中进行 PEPs 集成。不存在 PEPs 应该包含的单一位置，但可以考虑使用 API 原则作为起点。

## 请求授权决定
<a name="request-decision"></a>

PEP 必须向 PDP 申请授权决定。请求可以采取多种形式。请求授权决策的最简单、最便捷的方法是向 PDP 公开的 RESTful API（OPA 或已验证权限）发送授权请求或查询。如果您使用的是经过验证的权限，也可以使用 AWS SDK 调用该**IsAuthorized**方法来检索授权决定。在这种模式下，PEP 的唯一功能是转发授权请求或查询所需的信息。这可以像将 API 收到的请求作为输入转发给 PDP 一样简单。还有其他创建方法 PEPs。例如，您可以在本地将 OPA PDP 与以 Go 编程语言编写的应用程序作为库集成，而不必使用 API。

## 评估授权决定
<a name="evaluate-decision"></a>

PEPs 需要包括评估授权决策结果的逻辑。当公开 PDPs 为时 APIs，授权决策可能采用 JSON 格式并由 API 调用返回。PEP 必须评估此 JSON 代码，以确定所采取的操作是否获得授权。*例如，如果 PDP 旨在提供布尔*允许*或*拒绝*授权决定，则 PEP 可能只需检查此值，然后返回 HTTP 状态码 200 表示*允许*，返回 HTTP 状态码 403 表示拒绝。*这种将 PEP 作为访问 API 的先决条件的模式是一种易于实施且非常有效的模式，可以在 SaaS 应用程序中实现访问控制。在更复杂的场景中，PEP 可能负责评估 PDP 返回的任意 JSON 代码。撰写 PEP 时必须包含解释 PDP 返回的授权决策所必需的任何逻辑。由于 PEP 可能在应用程序的许多不同位置实现，因此我们建议您将您的 PEP 代码打包为所选编程语言的可重用库或工件。这样，您的 PEP 就可以轻松地集成到应用程序中的任何位置，而只需极少的返工。