基于 RBAC 模型的 RESTful API 设计

Posted 2023-02-19

【中文标题】基于 RBAC 模型的 RESTful API 设计

【英文标题】：RESTful API Design based on the RBAC model

【发布时间】：2020-05-03 21:44:00

【问题描述】：

面临的问题在于 RESTful API 的设计，该 API 可以在基于 RBAC 的解决方案中管理来自多个角色的请求。

目前我们有不同的资源可以被不同的用户访问，根据他们的权限可以有一个或多个角色。

我们尝试定义的 API 必须对客户端尽可能清晰，但又不能向 URL 添加额外的元数据，否则可能会损坏甚至与 REST 实践和定义发生冲突。因此，我们必须不惜一切代价避免在 URL 中包含有关角色的信息。该计划是使用 JWT 令牌，在其有效负载中携带所需的信息，以了解用户发出请求的权限。

提出了我们目前的情况，让我们举个例子并说明要解决的问题：

假设我们有 * 金融家 * 和 * 提供者 * 作为具有某些角色的用户，他们都想访问 ** attentions **（我们的资源）。我们是否应该在资源之前添加**注意**有关尝试访问资源的*用户*的信息？

这种情况下的端点应定义为（作为示例）：

https://example.com/api/v1/financiers/:id/attentions
https://example.com/api/v1/providers/:id/attentions

通过这种方式，我们试图通知相应的控制器我们希望针对特定角色/用户获得**关注**，在某种程度上，这些角色/用户是它们的子资源。

另一方面，我们可以简单地实现一个更简单的端点，如下所示：

https://example.com/api/v1/attentions

关于哪些注意力从数据库返回的逻辑现在应该以一种独特的方法实现，该方法必须处理这两个角色（以及可能在以下功能中出现的新角色）。所需的所有信息都必须从令牌的有效负载中获取，从而公开更通用的 API，并将 Web 客户端从根据角色调用哪个端点的责任中解放出来。

我想强调注意力是在微服务架构中管理的，因此检索它们的逻辑被收集在单个服务中。 API 网关从第一个解决方案路由两个（可能更多）端点的成本是在我们的特定情况下不丢弃的变量。

暴露了我们的现状：

我们将是处理此问题的最佳方法？ 是否有其他未考虑的替代方案可以简化角色管理并提供干净的 API 以向客户端公开？ 在第二种解决方案中，根据特定用户所拥有的角色，仅返回可访问的注意力是否正确？访问端点并仅根据其角色从该集合中获取部分资源（而不是全部）不是违反直觉吗？

我希望有人能澄清我们正在采取的方法，因为我发现关于这个问题的文献很少，也没有。

【参考方案1】：

这种过滤有多种解决方案，开发人员必须根据特定情况选择一种。

根据我的经验，我可以列出以下内容。

结构

当无法直接访问数据并且开发人员必须使用关系（即表 JOIN）时。在这种情况下，URL 必须同时包含主实体和子实体。在采用这种方法之前，一个很好的检查是询问是否可以将相同的 URL 与 POST 一起使用？

示例

如果我们必须获取分配给特定用户的角色列表或想要分配其他角色，那么我们可以使用

GET users/:uid/roles
POST users/:uid/roles

安全

在多租户系统中，每个用户都可以拥有他/她的私有资源，即禁止其他用户访问这些资源。开发者应保存租户信息并根据当前身份验证过滤资源，而不需要打扰客户端或在 URL 中要求任何其他信息

示例

用户的手机相册

GET photos
POST photos

搜索

如果它与安全或结构无关，但客户仍希望根据他的场景过滤结果集。那么开发人员应该使用查询字符串进行过滤。

示例

客户必须从他/她的收件箱或发件箱中获取消息，或者需要尚未阅读的消息。或者他/她想搜索他/她的收件箱

GET messages?folder=inbox
GET messages?folder=inbox&status=unread
GET messages?search=nasir

【讨论】：

如我所见，在这三种方法中，都不需要知道用户拥有哪些角色。一切都发生在后端的幕后，客户端只需负责调用一个通用端点，该端点将返回所请求的资源。暗示过滤响应的第三个解决方案将在后端已经决定返回给用户的资源中，因此用户甚至不知道同一集合中还有其他类似的资源无权访问.我们应该采用我当时提出的第二种方法吗？

是的！你明白了，你必须去 security 和关于角色列表，它可以用 jwt 编码，或者你可以使用提供的用户身份验证从数据库中获取它。