authorization - 微服务架构中的资源级授权
问题描述
我需要为一个基于微服务架构的应用程序设计一个授权方案。
我将专注于 3 个微服务来定义问题。
- API网关服务
- 项目服务 - 处理项目元数据信息，如（project_id、name、description ...）
- 计费服务 - 处理项目计费流程并保存（project_id、billing_information）
当前的授权模型需要 RBAC 和 ACL（基于资源），其中每个用户都定义了一组角色（管理员、项目经理等），并且还可以定义哪个用户可以通过其 ID 访问哪个项目（项目经理 X 可以访问项目 1,2 但不是 3,4)
问题数：
- 谁负责管理项目的 ACL？哪个用户可以访问哪个项目？（假设你可以有很多项目）
- 当用户在提供 project_id 时尝试访问 Project 服务或 Billing 服务时，应如何验证授权？
看到一些解决方案建议应该添加一个集中式微服务来运行此操作，并且出于性能原因它应该将其信息传播到其他服务（例如，如果用户想要获取他可以看到的所有相关项目 - 这将是很多如果项目服务将在他的服务中加入授权信息，则速度更快）。这可能会引发一个问题，即添加新的 ACL 对象并且授权对象将开始增长。
其他人说这应该在微服务级别处理 - 但是谁最终负责 ACL？如果是项目微服务，那么当计费服务需要授权时——它应该调用项目微服务吗？
解决方案
真的很难说什么是最好的解决方案，但我可以提出类似于我们之前使用的方案，它是集中用户角色管理加上对服务本身的授权检查的组合。
这个想法是拥有一个中央身份验证和授权服务，它将为您提供具有角色的用户信息（一个示例可能是中央 OAuth2）。在服务方面，您应该获取此信息并检查提供的角色是否允许。
对于 ACL，我认为您可以将该信息保留在资源端（项目服务）——允许访问资源的用户——因为它将在每个项目中指定。再次对服务进行第二次授权检查，并依次或一起进行角色检查。