OPA 的设计模型

使用开启的集中式 PDP PEPs APIs

APIs 模型上带有策略执行点 () 的集中式政策决策点 (PDPPEPs) 遵循行业最佳实践，为 API 访问控制和授权创建有效且易于维护的系统。这种方法支持几个关键原则：

• 授权和 API 访问控制应用于应用程序中的多个点。

• 授权逻辑独立于应用程序。

• 访问控制决策是集中化的。

此模型使用集中式 PDP 来做出授权决策。 PEPs 完全是 APIs 为了向 PDP 提出授权请求而实施的。下图显示了如何在假设的多租户 SaaS 应用程序中实现此模型。

应用程序流程（图中用蓝色编号标注说明）：

1. 使用 JWT 的经过身份验证的用户会向 Amazon CloudFront 生成一个 HTTP 请求。

2. CloudFront 将请求转发到配置为 CloudFront来源的 Amazon API Gateway。

3. 调用 API Gateway 自定义授权器来验证 JWT。

4. 微服务会响应请求。

授权和 API 访问控制流程（图中用红色编号标注说明）：

1. PEP 调用授权服务并传递请求数据，包括任何 JWTs数据。

2. 授权服务 (PDP) 获取请求数据并查询作为边车运行的 OPA 代理 REST API。请求数据用作查询的输入。

3. OPA 根据查询中指定的相关策略评估输入。如有必要，可以导入数据以做出授权决定。

4. OPA 将决策返回给授权服务。

5. 授权决定将返回给 PEP 并进行评估。

在此架构中，在 Amazon CloudFront 和 Amazon API Gateway 的服务终端节点以及每项微服务上 PEPs 请求授权决策。授权决定由带有OPA边车的授权服务（PDP）做出。您可以将此授权服务作为容器或传统服务器实例进行操作。OPA 边车在本地公开其 RESTful API，因此只有授权服务才能访问该 API。授权服务公开了一个单独的 API，可供使用。 PEPs让授权服务充当 PEPs 和 OPA 之间的中介，允许在 PEPs 和 OPA 之间插入任何可能需要的转换逻辑，例如，当 PEP 的授权请求不符合 OPA 预期的查询输入时。

您也可以将此架构与自定义策略引擎一起使用。但是，从 OPA 获得的任何优势都必须替换为自定义策略引擎提供的逻辑。

开启的集中式 PDP APIs 提供了一个简单的选项，可以为其创建强大的授权系统。 PEPs APIs它易于实现，还提供了一个可重复的接口 easy-to-use，用于为微服务 APIs、前端后端 (BFF) 层或其他应用程序组件做出授权决策。但是，这种方法可能会在您的应用程序中造成过多的延迟，因为授权决策需要调用单独的 API。如果存在网络延迟问题，则可以考虑使用分布式 PDP。

使用开启的分布式 PDP PEPs APIs

APIs 模型上带有策略实施点 () 的分布式策略决策点 (PDPPEPs) 遵循行业最佳实践，可创建有效的 API 访问控制和授权系统。与带 APIs模型的集中式 PDP 一样，此方法支持以下关键原则： PEPs

• 授权和 API 访问控制应用于应用程序中的多个点。

• 授权逻辑独立于应用程序。

• 访问控制决策是集中化的。

您可能想知道，为什么在分发 PDP 时，访问控制决策是集中的。尽管 PDP 可能存在于应用程序的多个位置，但它必须使用相同的授权逻辑来做出访问控制决策。在输入相同的情况下，所有这些都 PDPs提供相同的访问控制决策。 PEPs 完全是 APIs 为了向 PDP 提出授权请求而实施的。下图显示了如何在假设的多租户 SaaS 应用程序中实现这种分布式模型。

在这种方法中， PDPs 在应用程序的多个位置实现。对于具有可运行 OPA 并支持 PDP 的板载计算功能的应用程序组件，例如带边车的容器化服务或亚马逊弹性计算云 (Amazon) 实例，PDP 决策可以直接集成到应用程序组件中，而不必对集中式 PDP 服务进行 API 调用。 EC2 RESTful 这样做的好处是可以减少集中式 PDP 模型中可能遇到的延迟，因为并非每个应用程序组件都必须进行额外的 API 调用才能获得授权决策。但是，对于不具备直接集成 PDP 的板载计算功能的应用程序组件（例如 Amazon 或 Amazon API CloudFront Gateway 服务），在此模型中仍然需要集中式 PDP。

下图显示了如何在假设的多租户 SaaS 应用程序中实现集中式 PDP 和分布式 PDP 的组合。

应用程序流程（图中用蓝色编号标注说明）：

1. 使用 JWT 的经过身份验证的用户会向 Amazon CloudFront 生成一个 HTTP 请求。

2. CloudFront 将请求转发到配置为 CloudFront来源的 Amazon API Gateway。

3. 调用 API Gateway 自定义授权器来验证 JWT。

4. 微服务会响应请求。

授权和 API 访问控制流程（图中用红色编号标注说明）：

1. PEP 调用授权服务并传递请求数据，包括任何 JWTs数据。

2. 授权服务 (PDP) 获取请求数据并查询作为边车运行的 OPA 代理 REST API。请求数据用作查询的输入。

3. OPA 根据查询中指定的相关策略评估输入。如有必要，可以导入数据以做出授权决定。

4. OPA 将决策返回给授权服务。

5. 授权决定将返回给 PEP 并进行评估。

在此架构中，在 API Gateway 的服务端点 CloudFront 以及每项微服务的服务端点 PEPs 请求授权决策。微服务的授权决策由授权服务（PDP）做出，该服务与应用程序组件一起充当边车。这种模式适用于在容器或亚马逊弹性计算云 (Amazon) 实例上运行的微服务（或服务 EC2）。API Gateway 等服务的授权决策仍 CloudFront 需要联系外部授权服务。无论如何，授权服务都会公开一个可用的 API。 PEPs让授权服务充当 PEPs 和 OPA 之间的中介，允许在 PEPs 和 OPA 之间插入任何可能需要的转换逻辑，例如，当 PEP 的授权请求不符合 OPA 预期的查询输入时。

您也可以将此架构与自定义策略引擎一起使用。但是，从 OPA 获得的任何优势都必须替换为自定义策略引擎提供的逻辑。

开启的 PEPs 分布式 PDP APIs 提供了为其创建强大的授权系统的选项。 APIs它实现起来很简单，并且提供了一个可重复的接口 easy-to-use，用于为微服务 APIs、前端后端 (BFF) 层或其他应用程序组件做出授权决策。这种方法还具有减少集中式 PDP 模型中可能遇到的延迟的优点。

使用分布式 PDP 作为库

您也可以向以库或包形式提供的 PDP 请求授权决定，以便在应用程序中使用。OPA 可用作 Go 第三方库。对于其他编程语言，采用此模型通常意味着必须创建自定义策略引擎。