权限应存储在微服务体系结构中的何处？
我们目前正在构建一个服务( REST )，这个服务是由我们的主要应用程序调用的。主应用程序包含设置的用户/权限/角色，用于验证用户是否能够完成应用程序上的任务。用户角色关系是一对多的关系。
第三方API有不同的端点。我们现在需要为端点实现一个角色/权限类型系统。例如，角色A可以调用create/update端点，但不能破坏。
问题在于角色/权限在何处存储和验证REST服务。我们已经在主应用程序上设置了一个角色/权限，在这个设置中添加特定于财务的角色似乎是错误的选择。这还意味着REST服务不会包含逻辑，因此，如果稍后要从其他服务调用端点，则该服务还需要设置一个角色/权限。
一般的问题是
如果角色/权限、表和逻辑存储在REST服务( REST服务)上，我几乎肯定这是正确/最好的方法。
如何将API服务角色/权限分配给主应用程序的用户。可能需要设置包含特定于服务的角色的附加表(这仍然感觉很脏，因为我们有两个用户与角色相关的不同位置)。
另一个选项是在REST服务上有一个roles_users表，它将主用户ID与服务中的角色关联起来。
其他注意事项是，主应用程序将需要检查这些权限，几乎每个页面负载都需要检查是否应该显示某些菜单信息--我们显然可以缓存这些信息，因为它不应该经常更改。
框架是Laravel，但我认为这与问题无关。包括在内以防万一。
回答 2
Software Engineering用户
发布于 2018-11-05 16:03:41
将权限和身份验证放在单独的Auth服务上。
这将检查用户名/密码，并发出一个签名令牌，其中包含用户所处的所有角色。
然后，您的微服务可以根据公钥检查令牌的签名，并将用户角色与他们正在调用的方法所需的角色进行比较。
这种方法的好处是
- 您有一个了解用户和角色的地方。如果用户需要一个新角色，或者创建了一个新用户，您就不必找到用户需要的每个微服务，并将用户添加到每个微服务中。
- Microservices不需要调用一个中心位置来检查角色。角色列在随请求发送的令牌中，它们拥有auth服务的公钥，因此能够验证令牌不是假的。
- 有几个标准的auth流使用这个原则，例如O Auth，您可以下载各种预先编写的库。
Software Engineering用户
发布于 2018-11-05 16:46:56
谁能访问这个REST服务？如果答案是“只有您的应用程序”，那么您的服务完全有理由信任它的客户。
但是，如果REST服务必须获得信任才能成功地实现其规定的目标之一，则可能需要(例如)创建客户端可以传递给服务的某种令牌。例如，这个令牌可能是后端系统将识别为发起所有这些的系统用户的时间标识符的东西。
https://softwareengineering.stackexchange.com/questions/381010
复制相似问题
腾讯云开发者
