OPAL+OPA VS XACML

比较传统的XACML架构的授权流程和OPA + OPAL提供的授权流程，然后讨论两者的区别。

早在2013年，不同的开发者都在 宣布 或 争论 XACML的死亡 - 然而，XACML的目标是促进共同的术语和授权实现之间的互操作性仍然有效，它仍然是描述授权架构结构的一个坚实基础。

在过去的几年里，包括授权在内的IAM领域已经 发生了巨大的变化 ，并允许新的XACML替代方案被创建。这一重大转变是对日益先进的授权需求不断上升的结果，而这一需求是由日益复杂的应用程序及其向微服务和云原生结构迁移所产生的。随着技术的进步，左移和低/无代码开发人员的出现，以及对事件驱动的动态授权的需求，XACML的替代品必须发展起来。

OPA+OPAL就是这样一个XACML的替代品。 开放策略代理 （OPA）是一个开源项目，它是一个通用的策略引擎，可以满足任何策略执行的要求，统一整个堆栈的策略执行，而不依赖于实现细节。它可以与任何语言一起使用，网络协议支持任何数据类型，并快速评估和返回答案。OPA的策略规则是用Rego编写的--一种高级声明性（类似Datalog）语言。 值得注意的是，OPA只提供了XACML的PDP的替代方案（更多的是关于这个问题）。OPA由 OPAL （开放策略管理层） 加强 --另一个开源的解决方案，允许你轻松地保持你的授权层实时更新。 OPA和OPAL的结合为XACML提供了一个坚实的替代方案。

为了更好地理解这个替代方案，我们将比较传统的XACML架构的授权流程和OPA + OPAL提供的授权流程，然后讨论其中的区别。值得注意的是，虽然主要是一个基于属性的访问控制（ABAC）系统，但XACML也可以用来描述基于角色的访问控制（RBAC）和其他模型。

理解流程的几个基本术语

XACML的架构由几个不同的模块组成，这些模块构成了做出授权决定的过程。让我们来看看这些不同的部分。

• PEP - "政策执行点"： PEP拦截用户对资源的访问，并授予或拒绝用户所请求的资源的访问。PEP不做决定；他们执行这些决定。PEP有可能也会在通过请求之前调整请求或其结果（又称数据过滤）。PEP的例子是代码内控制流（即 "如果"）、中间件、反向代理和API网关。
• PDP - "政策决定点"： PDP根据相关政策和从分布式数据层汇总的数据快照评估授权请求，并做出授权决定。
• PAP - "策略管理点"： PAP负责管理PDP使用的所有相关策略。
• PIP - "策略信息点"： PIP是任何数据源（内部或外部），包含与做出策略决策有关的属性。
• PRP - "策略检索点"： PAP是策略的主要来源--它存储所有将被PDP使用的相关策略，并由PAP管理（在OPA中，它是一个bundle-server，而在OPAL中，这通常是一个Git仓库或一个HTTP bundle服务器）。

传统的XACML架构

让我们先回顾一下传统XACML的架构和它的授权流程：

1. 一切从用户（或自动化实体）与应用程序的交互开始。 用户发送一个 请求 ，以访问和执行应用程序中任何类型的资源的行动。在提交给应用逻辑之前，该请求要经过PEP。PEP负责批准或拒绝用户对资源的访问请求。

2. PEP将用户的请求翻译成XACML授权请求。需要注意的是，一个用户请求可以触发多个授权查询（因为它与多个资源交互）。

3. 为了知道该请求是否应该被批准或拒绝，PEP将授权请求发送给PDP。

4. PDP根据预先配置的XACML格式的策略做出授权决定。

5. 这些策略被存储在PRP中，并由PAP管理。

6. 如果需要，PDP 通过查询 相关的PIP 来获取任何额外的相关信息。

7. PDP做出决定（允许/拒绝/等）并将其返回给PEP。

8. 根据PDP的决定，用户被PEP授予或拒绝访问该资源。

OPA + OPAL架构

虽然基于类似的原则，OPA和OPAL提供了一个略有不同的授权模型，但有很大的好处。

1. 第一步与XACML相同--用户/自动化实体发送请求并通过PEP。

2. PEP将用户的请求转换为对PDP（本例中为OPA）的查询。

3. 这些查询由PEP提交给PDP（OPA），以了解该请求是否应该被批准或拒绝。到目前为止，很好--这里的情况有点不同。首先，OPA在其缓存中存储所有相关的政策。其次，政策是以代码形式表示的（在Rego中），不像XACML，它们是以配置形式表示的（如XML模式）。

4. PAP（在这种情况下，OPAL服务器）具有双重功能。它既是一个政策管理点，又是一个政策信息管理点。4.1 作为策略管理点 - OPAL服务器负责管理所有相关的策略，并在PDP内将其提供给OPA。策略以代码的形式存储在GIT库中（默认选项，虽然也有其他选项），它作为PRP。OPAL服务器接收来自PRP的策略更新，并指示OPAL客户端相应更新OPA的缓存。每当GIT中的策略发生变化时，它就会被OPAL服务器拉出来，并通过OPAL客户端推送到OPA的缓存中，这些客户端监听服务器（基于主题）并位于OPA实例的旁边。通过利用GIT和作为代码的策略，OPAL允许我们使用Gitops的最佳实践（例如，测试、代码审查、基准测试）。 通过这种方式，OPA始终保持实时更新最新的政策变化，而不需要重新部署。 4.2 作为政策信息管理点 --OPAL服务器根据选定的主题向PDP内的OPAL客户端通知PIP内的数据变化。随着客户端的更新，服务器发送关于如何查询PIPs的指令，OPAL客户端直接从PIPs中获取数据（根据指令），并以最新的信息更新OPA。由于这个过程是连续的， 存储在PDP缓存中的信息始终是最新的，以最准确的方式做出访问决策所需的最新数据。

5. PDP（OPA）做出决定（允许/拒绝/等）并将其返回给PEP。

6. 根据PDP（OPA）做出的决定，PEP要么授予用户访问该资源的权利，要么拒绝。

差异

从传统的XACML和OPA+OPAL的授权流程的差异中，我们可以注意到后者提供的三个重要的好处。

1. OPAL服务器能够接收来自GIT（或任何其他政策源）的更新，使OPA保持最新的政策-- 允许我们在飞行中进行政策修改，并以最小的延迟被PDP所利用。利用GIT仓库中的策略作为代码，可以使配置作为代码和Gitops普遍得到采用。

2. OPAL服务器不仅管理政策本身，而且还管理PIP，在做出政策决定时，通常需要从PIP获得额外的数据。OPAL客户端不断监听相关PIP（内部或外部数据库）的变化，并使用数据提取器使OPA的缓存不断更新，以达到授权决策所需的最新信息。因为这是一个持续的过程，而不是每次查询都做，所以 即使PIP不可用，OPA也可以在其缓存中拥有所有相关信息来做出政策决定 --防止PDP做出授权决定。

3. 虽然从我们描述的授权流程中看不出来，但需要注意的是， Rego中的策略 比XACML中的策略 更容易理解，更容易阅读/维护。

传统的XACML和OPA+OPAL之间的差异突出了近年来授权领域发生的巨大变化。OPAL实时接收数据和策略更新的能力允许创建事件驱动的动态授权。同时，OPA提供了定义更复杂的授权结构的能力，适合微服务和云原生结构。它的策略语言Rego更容易阅读/维护，并为低端/无代码的开发者提供可及性。OPAL是一个成熟的开源项目，它已经在保持数百个策略代理的实时更新。