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

Question

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

我将重点介绍3种微服务来定义问题。

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

当前的授权模型需要RBAC和ACL（基于资源），其中每个用户都定义了一组角色（ADMIN，Project Manager等），并且还可以定义哪个用户可以通过其ID访问哪个项目（Project Manager X可以访问项目1,2，但不能访问3,4）

问题数量：

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

看到一些解决方案建议，应该添加一个集中式微服务来运行此操作，并且出于性能方面的考虑，它应该将其信息传播到其他服务（例如，如果用户想要获取他可以看到的所有相关项目，这如果Project服务将授权信​​息加入其服务中，则速度会更快）。 这可能会带来一个问题，其中将添加新的ACL对象，并且授权对象将开始增长。

其他人说这应该在微服务级别上进行处理-但是谁最终负责ACL？如果是Projects微服务，那么当计费服务需要授权时，是否应该调用Projects微服务？

Answer 1

很难说什么是最佳解决方案，但是我可以提出与我们以前使用的类似的解决方案，它是集中式用户角色管理和对服务本身的授权检查的结合。

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

对于ACL，我认为您可以将该信息保留在资源方面（项目服务），即允许访问该资源的用户，因为每个项目都将指定该信息。然后再次对服务进行第二次授权检查，以及对角色进行一次或多次检查。