微服务架构中的资源级授权

Question

我需要为基于微服务架构的应用程序设计授权方案。

我将聚焦于三个微服务来定义问题：

1. API网关服务
2. 项目服务 - 处理项目元数据信息，如（project_id、名称、描述...）
3. 计费服务 - 处理项目计费过程并保存（project_id、billing_information）

当前的授权模型要求使用RBAC和ACL（基于资源的），其中每个用户都有一组定义好的角色（管理员、项目经理等），还可以定义哪个用户可以访问哪个项目按其ID（项目经理X可以访问1,2号项目但不能访问3,4号项目）。

问题数量：

1. 谁负责管理项目的ACL？哪个用户可以访问哪个项目？（假设有很多项目）
2. 当用户尝试提供project_id访问Project服务或Billing服务时，应该如何验证授权？

看到一些解决方案建议添加一个集中式微服务来运行此操作，并应为性能原因向其他服务传播其信息（例如，如果用户想要获取他可以看到的所有相关项目，这样做将更快，如果Project服务将加入授权信息，它的服务）。这可能会引发一个问题，即新的ACL对象将被添加，授权对象将开始增长。

其他人认为这应该在微服务级别处理 - 但最终谁负责ACL？如果是Projects 微服务，则当Billing服务需要授权时，它应调用Projects微服务吗？

- sborpo

Answer 1

很难说什么是最好的解决方案，但我可以提出类似于我们之前使用的方法，即集中式用户角色管理加上对服务本身的授权检查的组合。

这个想法是有一个中央认证和授权服务，它将为您提供带有角色的用户信息（例如中央OAuth2）。然后在服务端，您应该获取此信息并检查所提供的角色是否被允许。

对于ACL，我认为您可以在资源侧（项目服务）保留该信息 - 允许访问资源的用户 - 因为它将针对每个项目进行指定。然后再与角色检查一起或分别在服务上进行第二次授权检查。

- cool

---

谢谢，你对计费服务有什么看法 - 它也需要授权访问其项目计费信息 - 是否应该通过远程调用项目服务来进行授权？ - sborpo

我可能错误地假设您需要访问项目服务，即使调用是来自计费服务以获取产品数据。因此，在这种情况下，您无需在计费服务上执行任何额外操作，因为项目服务将保护数据。如果不是这种情况，并且计费服务拥有其所需的一切，不需要向项目服务请求数据，则根据总体要求，您可以将此ACL信息保留在ProjectService中，或者将其提取出来。 - cool

它具有必要的project_id和所有计费信息，但如果用户直接访问它，则计费服务仍需要验证用户是否具有此特定project_id的权限-那么计费服务如何做到这一点？尝试询问Projects Service（为每个请求进行另一个API调用）？还是保持本地同步授权信息的数据？ - sborpo

对于将ACL数据保留在ProjectService的情况，您提出的两种解决方案都可能有效。这取决于您系统中的调用次数。您可以直接调用ProjectService或从ProjectService流式传输更改到您的服务并在本地使用它。但是，如果您有多个客户端需要了解客户端允许的项目ID，则可以考虑将此信息也保存在一个集中的位置，并在可行的情况下附加到安全令牌上。 - cool