实施 PEP

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

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

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

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

请求授权决定

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

评估授权决定

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