实体/资源的 RESTful API 授权? [英] RESTful API authorization on entities/resources?

问题描述

我正在一个具有非常复杂的访问控制规则的系统中开发 API.很多时候，需要复杂的 SQL 查询来确定用户是否对特定资源具有读或写访问权限.这会在我们的客户端应用程序中造成很多复杂性和冗余，因为它们必须了解所有这些规则才能确定是否向用户显示每个对象的 CRUD 选项.

我的目标是减少客户端的大部分复杂性，并将所有复杂的逻辑包含在 API 中.通过这种方式，针对我们的 API 编写的新客户端应用程序可以在确保 UI 仅向用户显示有效选项时避免在他们这边重新实现复杂的访问规则逻辑.

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

选项 1

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

<块引用>

获取/listing/5

<代码>{身份证":5，"address": "富街123号","city": "纽约","state": "纽约",价格":457000，状态":待定"，"_allowed_actions": ["READ", "UPDATE", "DELETE"]}

仍然不确定如何与客户端相关联，他们是否有权使用此方法创建资源实体的实例，但也许客户端只需要保持对权限结构的足够了解即可自行确定.创建实例的访问规则通常没有 READ/UPDATE/DELETE 访问规则复杂，因此看起来还不错.

选项 2

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

<块引用>

GET/access-query/listing/5

<代码>{"allowed_actions": ["READ", "UPDATE","DELETE"]}

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

<块引用>

GET/access-query/listing

<代码>{"allowed_actions": ["READ", "CREATE", "UPDATE", "DELETE"]}

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

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

我并不特别喜欢这两种方法中的任何一种，但目前我只能想到它们.有没有更好的方法来解决这个问题?

解决方案

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

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

有一个称为基于属性的访问控制 (ABAC) 的模型，它定义了一种细粒度的外部化授权方法.美国国家标准与技术研究院 NIST 制作了一份

用于 Eclipse 的 ALFA 插件 - 一个免费工具编写 XACML 策略.

XACML 开发者社区

XACML 有供应商和开源实现:

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

HTH，大卫.

I am working on an API in a system that has very complex access control rules. Often times there are complex SQL queries required to determine if a user has read or write access to a particular resource. This causes a lot of complexity and redundancy in our client applications as they have to know all these rules in order to determine whether to present the user with CRUD options for each object.

My goal is to reduce much of the complexity on the client side and house all the complex logic in the API. This way new client applications written against our API can avoid re-implementing the complex access rule logic on their side when ensuring that the UI only presents valid options to the user.

I am not sure what the best way is to handle this. I'm considering two different options but I don't know if there is a better or more standard way to expose generic access information to callers of an API.

Option 1

When a caller makes a GET request on a resource entity or collection of them, every returned entity will return an _allowed_actions field attached, which is an array of actions the caller is allowed to perform on that entity. For example, requesting a Listing object may result in the following response.

GET /listing/5

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

Still unsure how to relate to clients whether they have the authority to create instances of a resource entity using this method, but perhaps the client will simply need to maintain enough understanding of the permission structure to determine this on its own. The access rules around creating instances are typically less complex than the READ/UPDATE/DELETE access rules so that doesn't seem too bad.

Option 2

Create a meta-API, which clients can make requests to in order to determine what actions they can perform on each resource. For example, checking what the client can do with a listing:

GET /access-query/listing/5

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

And checking what options are allowed for listings in general, including CREATE:

GET /access-query/listing

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

The benefit of this approach is that it allows callers to have a full understanding of what they can do on every resource in a generic way. This way clients wouldn't have to understand that the "create_listing" permission AND a non-probationary user status are required required in order to create listings. They can simply query for this information ahead of time.

The downside to this approach is that it increases the amount of requests. Rather than require clients to have an understanding of the permissions logic, they now have to query once to determine what they can do and a second time to do it.

I don't particularly care for either of these methods but they're all I can come up with at the moment. Is there a better way to go about this?

解决方案

What you are looking for is fine-grained, externalized authorization:

• fine-grained: you want to create authorization policies that take into account multiple parameters or attributes and possibly relationships between the client (the requestor) and the targeted entity e.g. a listing in your case.
• externalized: you want to decouple the business logic from the authorization logic. In your question you complain about how complex the code and the SQL statements are becoming. This is a direct consequence of not clearly separating business logic from authorization logic.

There is a model called attribute-based access control (ABAC) that defines an approach to fine-grained externalized authorization. NIST, the National Institute of Standards and Technology, has produced a report on ABAC which you can read online.

OASIS, the organization for the advancement of structured information standards, has defined a standard called XACML (eXtensible Access Control Markup Language) to implement ABAC.

XACML brings you:

• an architecture as illustrated below
  • The policy enforcement point (PEP) intercepts your API calls. It protects your API, inspects the messages and sends an authorization request to the policy decision point (PDP).
  • The policy decision point (PDP) evaluates incoming authorization requests from the PEP against a set of authorization policies written in XACML. The PDP eventually reaches a Permit or Deny decision. To reach decisions it may need to look up additional attribute values from databases, web services, LDAP, or files. These are called policy information points in the architecture.
• a policy language: the XACML policy language is attribute-based which means it uses attributes to define what can be allowed and what is not. For instance, you could define rules such as:
  • a real estate agent can see all the listings if and only if the listing location == the agent location
  • a real estate agent can edit a listing if and only if he/she owns the listing
  • a real estate agent can close a listing if and only if the listing's item is sold and if and only if the agent is the person that sold the item.
• a request/response scheme: XACML also defines a way to query the PDP and to get responses back. A PDP can be queried either via single questions or via multiple questions in a single request e.g.:
  • Can Alice view listing 123? Yes, permit.
  • Can Alice view, edit, or delete listing 123? Permit; Deny; Deny.

With a XACML-based approach, you get to maintain your business logic and your API separate from the authorization logic. This has several benefits:

1. you can always reimplement the API and keep the same authorization model
2. you can easily expand your API without having to rewrite the authorization
3. you can change your authorization logic independently of your code
4. you can audit your authorization logic more easily
5. your authorization logic is technology-neutral. It works for REST APIs, web services, databases, and more

I recommend you check out the following resources:

1. the OASIS XACML website
2. the ALFA plugin for Eclipse - a free tool to write XACML policies.
3. The XACML developer community

There are both vendor and open-source implementations of XACML:

• Axiomatics is a vendor solution that provides both .NET and Java XACML implementations
• SunXACML is a long-standing open source Java XACML implementation

HTH, David.

这篇关于实体/资源的 RESTful API 授权?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！