api - 对实体/资源进行 RESTful API 授权？

Question

我正在一个具有非常复杂的访问控制规则的系统中开发 API。通常需要复杂的 SQL 查询来确定用户是否具有对特定资源的读取或写入访问权限。这会导致我们的客户端应用程序变得非常复杂和冗余，因为它们必须了解所有这些规则才能确定是否向用户提供每个对象的 CRUD 选项。

我的目标是减少客户端的大部分复杂性并将所有复杂逻辑容纳在 API 中。这样，根据我们的 API 编写的新客户端应用程序可以避免在其端重新实现复杂的访问规则逻辑，同时确保 UI 只向用户提供有效选项。

我不确定处理这个问题的最佳方法是什么。我正在考虑两种不同的选择，但我不知道是否有更好或更标准的方法来向 API 调用者公开通用访问信息。

选项 1

当调用者对资源实体或其集合发出 GET 请求时，每个返回的实体将返回附加的 _allowed_actions 字段，该字段是允许调用者对该资源执行的操作数组实体。例如，请求 Listing 对象可能会导致以下响应。

GET /listing/5

{
 "id": 5,
 "address": "123 Foo Street",
 "city": "New York",
 "state": "New York",
 "price": 457000,
 "status": "pending",
 "_allowed_actions": ["READ", "UPDATE", "DELETE"]
}

仍然不确定如何与客户端联系，他们是否有权使用此方法创建资源实体的实例，但也许客户端只需要对权限结构保持足够的了解即可自行确定这一点。创建实例的访问规则通常没有读取/更新/删除访问规则复杂，因此看起来并不算太糟糕。

选项 2

创建一个元 API，客户端可以向该 API 发出请求，以确定他们可以对每个资源执行哪些操作。例如，检查客户端可以对列表执行哪些操作:

GET /access-query/listing/5

{
 "allowed_actions": ["READ", "UPDATE","DELETE"]
}

并检查一般列表允许哪些选项，包括创建:

GET /access-query/listing

{
 "allowed_actions": ["READ", "CREATE", "UPDATE", "DELETE"]
}

这种方法的好处是，它允许调用者以通用方式充分了解他们可以对每个资源执行哪些操作。这样，客户就不必了解创建列表需要“create_listing”权限和非试用用户状态。他们可以简单地提前查询这些信息。

这种方法的缺点是会增加请求量。现在，他们不再要求客户端了解权限逻辑，而是必须查询一次以确定他们可以做什么，然后再查询一次。

我并不特别关心这两种方法，但目前我只能想到这些方法。有没有更好的方法来解决这个问题？

Answer 1

您正在寻找的是细粒度的外部化授权:

• 细粒度:您希望创建考虑多个参数或属性以及客户端(请求者)和目标实体之间可能的关系的授权策略，例如您案例中的列表。
• 外部化:您希望将业务逻辑与授权逻辑分离。在你的问题中，你提示代码和 SQL 语句变得多么复杂。这是业务逻辑与授权逻辑没有明确分离的直接后果。

有一种称为基于属性的访问控制 (ABAC) 的模型，它定义了细粒度外部化授权的方法。 NIST(美国国家标准与技术研究所)制定了 report on ABAC您可以在线阅读。

OASIS 是结构化信息标准推进组织，定义了一个名为 XACML 的标准。 (可扩展访问控制标记语言)来实现ABAC。

XACML 为您带来:

• 架构如下图所示
  • 策略执行点 (PEP) 拦截您的 API 调用。它保护您的 API、检查消息并向策略决策点 (PDP) 发送授权请求。
  • 策略决策点 (PDP) 根据一组用 XACML 编写的授权策略评估来自 PEP 的传入授权请求。 PDP 最终做出允许或拒绝的决定。为了做出决策，它可能需要从数据库、Web 服务、LDAP 或文件中查找其他属性值。这些在架构中称为策略信息点。
• 策略语言:XACML 策略语言是基于属性的，这意味着它使用属性来定义可以允许的内容和不允许的内容。例如，您可以定义如下规则:
  • 当且仅当房源位置 == 代理位置时，房地产经纪人才能查看所有房源
  • 当且仅当房地产经纪人拥有该列表时，他/她才可以编辑该列表
  • 当且仅当房源的商品已售出且当且仅当经纪人是该商品的出售者时，房地产经纪人才可以关闭房源。
• 请求/响应方案:XACML 还定义了一种查询 PDP 并获取响应的方法。可以通过单个问题或单个请求中的多个问题来查询 PDP，例如:
  • Alice 可以查看列表 123 吗？是的，允许。
  • Alice 可以查看、编辑或删除列表 123 吗？允许;否定;否认。

通过基于 XACML 的方法，您可以将业务逻辑和 API 与授权逻辑分开来维护。这有几个好处:

1. 您随时可以重新实现 API 并保持相同的授权模型
2. 您可以轻松扩展您的 API，而无需重写授权
3. 您可以独立于代码更改授权逻辑
4. 您可以更轻松地审核您的授权逻辑
5. 您的授权逻辑是技术中立的。它适用于 REST API、Web 服务、数据库等

我建议您查看以下资源:

1. OASIS XACML website
2. ALFA plugin for Eclipse - 编写 XACML 策略的免费工具。
3. XACML developer community

XACML 有供应商和开源实现:

• Axiomatics 是一个供应商解决方案，提供 .NET 和 Java XACML 实现
• SunXACML 是一个长期存在的开源 Java XACML 实现

HTH， 大卫。