使用开放策略代理 (OPA) 作为 ABAC 系统
using open policy agent (OPA) as an ABAC system
我有一个项目需要 ABAC 来控制我的项目资源的访问权限。我一直在关注 OPA 和 authzforce 作为实施 ABAC 的选项，OPA 看起来可能没有 authzforce 复杂。我看到 OPA 将自己与其他系统和范例进行比较，但它为 ABAC 提供的示例还有很多不足之处。主要是因为 ABAC 需要使用点来执行策略，围绕策略做出决策，获取策略决策的主题和对象属性。我觉得 OPA 除了最后一部分涵盖了所有内容，但很难判断这是不是真的，因为他们的 ABAC 示例只是一次性的。
我一直在整个互联网上寻找 OPA 被用作 ABAC 实现的例子，但我没有找到任何东西。
我的项目是一个 Web 应用程序，它允许最终用户创建资源并为其资源创建策略。我计划为最终用户创建一个 UI 来创建他们的策略。我的计划是抽象出它的编码方面，而是给他们下拉菜单和按钮，这 UI 将在幕后使用自定义语法，我将其解释为 OPA 策略。
我遇到的主要问题是如何将其实现为 ABAC，它是否与构建将获取主题、对象和环境的属性并在它与 OPA 之间创建粘合剂的部分一样简单（本质上是创建一个 PIP）因为 OPA 本身似乎是事实上的 PEP 和 PDP？
我感觉自己快被文档淹没了，而且 OPA 自己的文档中似乎缺少很多内容来解释如何做到这一点。
OPA looks like it might be less complicated than authzforce
这两种方法各有利弊。首先，您意识到 OPA 和 AuthZForce 都是 ABAC 实现（您可以在 ABAC here and here 上阅读更多内容）。
OPA
Open Policy Agent 是一种相对新颖的模型，主要（但不仅限于）解决基础设施（例如 Kubernetes）的细粒度授权问题。他们甚至为 Istio 和 Kubernetes 预建了集成点。 OPA 提供了 PEP（执行/集成）和 PDP（政策决策点），尽管它不一定那样称呼它们。它使用的语言称为 REGO（DATALOG 的派生词）。
OPA itself appears to be a defacto PEP and PDP
是的，您完全正确，这给您带来了实施 PIP 替代方案的负担。
I feel like I'm drowning in the documentation and there seems to be quite a bit missing from OPAs own docs to explain how this can be done.
联系 Styra - 他们围绕 OPA 销售服务。或者重新考虑您的选择并查看 XACML（见下文）。
缺点
- 语言（REGO）不太好懂
- 语言不规范
- OPA 不支持策略信息点 (PIP) - 这是设计使然。
实施
I've been looking all over the internet for examples of OPA being used as an implementation for ABAC but I haven't found anything.
看看 work they did at Netflix. That's the main implementation I am aware of. You can also reach out to Styra，OPA 背后的公司，他们将能够提供帮助。
AuthZForce
AuthZForce 是 XACML（可扩展访问控制标记语言 xacml) standard. It provides a full ABAC implementation (PAP, PEP, PDP, PIP). It's part of Fiware (an open source initiative) and it's actively developed by a team at Thales。
的开源 Java 实现
AuthZForce 缺点
- 它似乎没有用于编写策略的图形界面。我找到了对 KEYROCK PAP 的引用，但看不到任何屏幕截图
- 不支持ALFA授权缩略语
实施
您可以考虑许多其他 XACML 实现（开源和商业）：
- AT&T XACML
- SunXACML
- WSO2 - 他们的 WSO2 身份服务器平台的一部分 - 它叫做 Balana
- Axiomatics（商业 - 这是我工作的地方） - 我们有大量使用我们平台的客户群，从财富 50 强公司到敏捷的初创公司。
XACML 和 ALFA 的优势
XACML/ALFA 的主要优势之一是它们是标准并被广泛采用。该标准自 2001 年以来一直存在，并与其他标准互操作，例如SAML、OAuth 和 SCIM。
也许最具体的答案是detailed description of how Chef Automate uses OPA to implement application authorization。
更一般地说，我们正在计划一个指南，描述如何使用 OPA 进行应用程序授权——它需要比 SO 答案更详细的信息。但是使用 OPA（或任何策略引擎）进行应用程序授权在一定程度上取决于您的应用程序、它的体系结构、您的 SLA 等。但这里有几个需要考虑的关键问题：
- 政策：您的最终用户政策需要多少表现力？他们只是定义用户属性或用户角色，还是也将用户 attributes/roles 映射到权限？ OPA 允许您将这些最终用户策略征求为 JSON 对象，然后编写使用这些 JSON 对象做出决策的策略规则。为了提高效率，您可以 compile those JSON objects into bona-fide OPA rules.
- Enforcement：你需要在哪里强制执行授权策略（例如网关、微服务、数据库）？您对延迟、数据大小、数据库查询语言的表达能力的要求都会影响这个决定。 OPA 足够灵活，可以帮助解决所有这些问题，并且有几个特定的集成可以提供帮助：Envoy and similar service-mesh systems for microservices and SQL/ElasticSearch for databases.
- 数据：有多少属性数据，它改变的频率如何，你需要什么样的一致性保证，你有什么机制将数据放入OPA（例如缓存、事件流）。这是一个guide for injecting data into OPA；它使用 LDAP/AD 作为示例数据源，但原则对于任何数据源都是相同的。
我们总是很乐意讨论您的应用程序的详细信息，并帮助您找到适合 OPA 的产品。欢迎随时联系 OPA slack channel.
我有一个项目需要 ABAC 来控制我的项目资源的访问权限。我一直在关注 OPA 和 authzforce 作为实施 ABAC 的选项，OPA 看起来可能没有 authzforce 复杂。我看到 OPA 将自己与其他系统和范例进行比较，但它为 ABAC 提供的示例还有很多不足之处。主要是因为 ABAC 需要使用点来执行策略，围绕策略做出决策，获取策略决策的主题和对象属性。我觉得 OPA 除了最后一部分涵盖了所有内容，但很难判断这是不是真的，因为他们的 ABAC 示例只是一次性的。
我一直在整个互联网上寻找 OPA 被用作 ABAC 实现的例子，但我没有找到任何东西。
我的项目是一个 Web 应用程序，它允许最终用户创建资源并为其资源创建策略。我计划为最终用户创建一个 UI 来创建他们的策略。我的计划是抽象出它的编码方面，而是给他们下拉菜单和按钮，这 UI 将在幕后使用自定义语法，我将其解释为 OPA 策略。
我遇到的主要问题是如何将其实现为 ABAC，它是否与构建将获取主题、对象和环境的属性并在它与 OPA 之间创建粘合剂的部分一样简单（本质上是创建一个 PIP）因为 OPA 本身似乎是事实上的 PEP 和 PDP？
我感觉自己快被文档淹没了，而且 OPA 自己的文档中似乎缺少很多内容来解释如何做到这一点。
OPA looks like it might be less complicated than authzforce
这两种方法各有利弊。首先，您意识到 OPA 和 AuthZForce 都是 ABAC 实现（您可以在 ABAC here and here 上阅读更多内容）。
OPA
Open Policy Agent 是一种相对新颖的模型，主要（但不仅限于）解决基础设施（例如 Kubernetes）的细粒度授权问题。他们甚至为 Istio 和 Kubernetes 预建了集成点。 OPA 提供了 PEP（执行/集成）和 PDP（政策决策点），尽管它不一定那样称呼它们。它使用的语言称为 REGO（DATALOG 的派生词）。
OPA itself appears to be a defacto PEP and PDP
是的，您完全正确，这给您带来了实施 PIP 替代方案的负担。
I feel like I'm drowning in the documentation and there seems to be quite a bit missing from OPAs own docs to explain how this can be done.
联系 Styra - 他们围绕 OPA 销售服务。或者重新考虑您的选择并查看 XACML（见下文）。
缺点
- 语言（REGO）不太好懂
- 语言不规范
- OPA 不支持策略信息点 (PIP) - 这是设计使然。
实施
I've been looking all over the internet for examples of OPA being used as an implementation for ABAC but I haven't found anything.
看看 work they did at Netflix. That's the main implementation I am aware of. You can also reach out to Styra，OPA 背后的公司，他们将能够提供帮助。
AuthZForce
AuthZForce 是 XACML（可扩展访问控制标记语言 xacml) standard. It provides a full ABAC implementation (PAP, PEP, PDP, PIP). It's part of Fiware (an open source initiative) and it's actively developed by a team at Thales。
的开源 Java 实现AuthZForce 缺点
- 它似乎没有用于编写策略的图形界面。我找到了对 KEYROCK PAP 的引用，但看不到任何屏幕截图
- 不支持ALFA授权缩略语
实施
您可以考虑许多其他 XACML 实现（开源和商业）：
- AT&T XACML
- SunXACML
- WSO2 - 他们的 WSO2 身份服务器平台的一部分 - 它叫做 Balana
- Axiomatics（商业 - 这是我工作的地方） - 我们有大量使用我们平台的客户群，从财富 50 强公司到敏捷的初创公司。
XACML 和 ALFA 的优势
XACML/ALFA 的主要优势之一是它们是标准并被广泛采用。该标准自 2001 年以来一直存在，并与其他标准互操作，例如SAML、OAuth 和 SCIM。
也许最具体的答案是detailed description of how Chef Automate uses OPA to implement application authorization。
更一般地说，我们正在计划一个指南，描述如何使用 OPA 进行应用程序授权——它需要比 SO 答案更详细的信息。但是使用 OPA（或任何策略引擎）进行应用程序授权在一定程度上取决于您的应用程序、它的体系结构、您的 SLA 等。但这里有几个需要考虑的关键问题：
- 政策：您的最终用户政策需要多少表现力？他们只是定义用户属性或用户角色，还是也将用户 attributes/roles 映射到权限？ OPA 允许您将这些最终用户策略征求为 JSON 对象，然后编写使用这些 JSON 对象做出决策的策略规则。为了提高效率，您可以 compile those JSON objects into bona-fide OPA rules.
- Enforcement：你需要在哪里强制执行授权策略（例如网关、微服务、数据库）？您对延迟、数据大小、数据库查询语言的表达能力的要求都会影响这个决定。 OPA 足够灵活，可以帮助解决所有这些问题，并且有几个特定的集成可以提供帮助：Envoy and similar service-mesh systems for microservices and SQL/ElasticSearch for databases.
- 数据：有多少属性数据，它改变的频率如何，你需要什么样的一致性保证，你有什么机制将数据放入OPA（例如缓存、事件流）。这是一个guide for injecting data into OPA；它使用 LDAP/AD 作为示例数据源，但原则对于任何数据源都是相同的。
我们总是很乐意讨论您的应用程序的详细信息，并帮助您找到适合 OPA 的产品。欢迎随时联系 OPA slack channel.