基于角色的访问控制验证微服务
如果我有多个应用程序，并且想使用单个Auth Microservice，该如何处理基于角色的访问控制？
假设我将一个凭据对象发送给带有不同令牌，用户ID和域（用户登录到中的应用程序）的用户。类似：
Credential {
String userid;
string domain; // defines which application the user has signed up for
string signature;
.....
}
游戏可能没有多个角色，但是电子商务应用程序肯定会扮演所有者，推销员，经理等角色。
那么，如果我想拥有集中式的授权服务，该问题如何解决？
更多的解释：
假设我有3个应用程序：
- 游戏
- ecommerece
- 一个像媒体这样的博客网站，
每个网站都独立地是单独的微服务。我想为所有此应用程序实施中央验证微服务。
因此，游戏可能没有太多角色，但是Ecommerece和Blog网站可能具有管理员，主持人，商店所有者，推销员等，
因为Auth Microservice无法知道我将来可能有多少个应用程序，所以我无法实施RBAC部分在验证服务中吧？
因此，如果我的身份验证服务仅处理身份验证，我该如何解决授权部分？
If I have multiple applications and want to use a single auth microservice how should I handle the role based access control?
Let's assume I send a credential object back to the user that carries the different tokens, userid and the domain(application the user signed into). Something like:
Credential {
String userid;
string domain; // defines which application the user has signed up for
string signature;
.....
}
A game might not have multiple roles but a ecommerce application will definitely have roles like owner, salesman, manager etc.
So how can this issue be solved if I wanted to have a centralized auth service?
A bit more explanation:
Let's assume I have 3 applications:
- Game
- Ecommerece
- A blog site like medium
Each of them are separate microservice on their own. And I want to implement a central auth microservice for all of this application.
So a game might not have lot of roles but ecommerece and blog site may have admin, moderators, shop owners, salesman etc etc.
Since the auth microservice has no way to know how many applications I might have in future I cannot implement the RBAC part in auth service right?
So if my auth service only handles the authentication how can I solve the authorization part?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
让我尝试回答，但在微服务世界中，它始终取决于用例。你也快到了。
你是对的，你可以单独实现 RBAC，但你肯定有一个微服务允许为游戏、Ecomm 和博客配置 RBAC。现在，当在授权服务内分配或更改任何角色或权限时，它会发布消息，并且可以由博客、ecomm 等其他服务使用，并且它们会将该用户/角色/权限存储到自己的 localdb 中。通过这种方式，您就有了一个处理配置的服务。
第 2 点成为核心，模块需要了解另一个服务中使用的所有权限/角色。因此，他们要么通过消息获取信息，要么通过 http 调用获取信息，因为角色/权限不会经常更改，因此不存在此类问题。如果有问题，那么消息传递也会有所帮助。
另一个解决方案是创建处理 RBAC 的单独包，但该包将与其他服务并排。因此，这些服务可以处理自己的角色，但这并不好，因为现在角色配置分散在服务之间。
Let me try to answer but in Microservice world, it always depends on use cases. Also you almost there.
You are right that you can implement RBAC separately but you definitely have one Microservice that allow to configure RBAC for Game, Ecomm and blog. Now when any role or permission is being assigned or change inside authorization service, it publish the message and it can be used by other service like blog, ecomm and they will store that user/role/permissions into their own localdb. By this way you have one service that handle the configuration.
Point 2 become central and that modules needs to know about all permissions/role used in another service. So either they get information via message or http call as Role/permission not frequently change so no such issue. If it is issue then messaging also will help.
Another solution is to create separate package that handle RBAC but that package will be side by side with other services. So those service can handle its own role but this is not good as now role configuration scatter across services.
我建议您研究一下 OAuth，它是广泛用于此用例的访问委托的开放标准。
I suggest you look into OAuth, it is an open standard for access delegation widely used for this use case.
我要说的是这取决于您如何部署该解决方案，例如Docker-warm或Kubernetes编排平台。您可以使用Traefik（或Nginx） + Autheria之类的东西。 Traefik充当您的集中入口，Authelia照顾了该验证。使用外部LDAP，您可以具有非常灵活的RBAC配置，并具有多因素auth等功能的附加值。您无需构建自己的RBAC解决方案。
也可以配置Traefik，以便您的客户端访问游戏服务还是电子商务服务，如果未经认证，它将始终查询Authelia。
希望这会有所帮助。
I would say this depends on how you deploy this solution e.g. a docker-swarm or kubernetes orchestration platform. You could use something like Traefik (or nginx) + Authelia. Traefik acts as your centralized ingress, authelia takes care of the auth. With external LDAP, you can have a very flexible RBAC configuration with the added value of features like multi-factor auth. You dont need to build your own RBAC solution.
Traefik can also be configured such that whether your clients access the game service, or the ecommerce service, if they are not authenticated, it will always query authelia.
Hope this helps.