关于微服务架构的讨论很多。我缺少的——或者我还不明白的是，如何解决安全和用户身份验证的问题？
例如:我开发了一个微服务，它为工作流引擎提供了一个 Rest Service 接口(interface)。该引擎基于 JEE，并在 GlassFish 或 Wildfly 等应用服务器上运行。 工作流引擎的核心概念之一是，每次调用都以用户为中心。这意味着根据当前用户的角色和访问级别，工作流引擎会产生单独的结果(例如，以用户为中心的任务列表或处理取决于用户在流程中的角色的打开任务)。
在我看来，因此无法从任何地方访问服务。例如，如果有人计划实现一个基于 Ajax 的现代 JavaScript 应用程序，该应用程序应该使用工作流微服务，那么存在两个问题:
1) 为避免 JavaScript/Ajax 的跨脚本问题，JavaScript Web 应用程序需要部署在与微服务运行相同的域下
2) 如果微服务强制进行用户身份验证(在我的场景中就是这种情况)，则应用程序需要提供透明的身份验证机制。
如果客户端需要访问多个以用户为中心的微服务来强制进行用户身份验证，情况就会变得更加复杂。 我总是最终得到一个架构，其中所有服务和客户端应用程序都运行在同一域下的同一应用程序服务器上。
如何解决这些问题？这种架构的最佳实践是什么？
最佳答案
简答:检查 OAUTH，并管理每个需要访问其他微服务的微服务中的凭据缓存。我所说的“管理”是指注意安全性。特别注意谁可以访问这些凭据并让网络拓扑成为您的 friend 。创建一个 DMZ 层和其他反射(reflect)微服务依赖关系图的内部层。
答案很长，请继续阅读。您的问题是一个很好的问题，因为尽管您的问题经常出现，但没有简单的 Elixir 可以满足您的需求。
与我目前看到的与微服务相关的所有内容一样，没有什么是真正新鲜的。每当您需要让分布式系统代表某个用户执行操作时，您都需要分布式凭据来启用此类解决方案。自大型机时代以来就是如此。没有办法违反。
Auto SSH是，在某种意义上，这样的事情。也许这听起来像是描述简单事物的一种美化方式，但最终，它使一台机器中的进程能够使用另一台机器中的服务。
在网格世界中，Globus Toolkit ，例如，基于其 distributed security使用以下内容:
- X.509 证书；
- MyProxy - 管理凭据存储库并帮助您定义一系列证书颁发机构，直至找到根证书颁发机构，默认情况下应受信任；
- OpenSSH 的扩展，它是 Linux 发行版事实上的标准 SSH 实现。
OAUTH也许是你需要的。这是一种提供额外限制的授权方式。例如，假设某个用户对某个服务具有读写权限。当您发出 OAUTH 授权时，您不一定将全部用户权力授予第三方。您只能授予读取权限。
另一个答案中提到的 CORS 在最终客户端(通常是 Web 浏览器)需要跨网站单点登录时很有用。但似乎您的问题更接近于一个集群，其中有许多由您管理的微服务。不过，您可以利用 Grid 领域开发的解决方案来确保跨站点分布的集群的安全性(例如，出于高可用性的原因)。
完全的安全是无法实现的。因此，如果凭据永远有效，或者如果您没有足够小心地将它们保密，那么所有这些都是没有用的。为此，我建议使用层对网络进行分区。每一层都有不同程度的保密性和对外暴露程度。
如果您不希望负担允许 OAUTH 所需的基础设施，您可以使用基本 HTTP 或创建自己的 token 。
使用 basic HTTP authentication 时，客户端需要在每个请求上发送凭据，因此无需在服务器端保持 session 状态以进行授权。
如果您想创建自己的机制，请更改您的登录请求，以便返回一个 token 作为对成功登录的响应。具有相同 token 的后续请求将充当基本 HTTP 身份验证，其优势在于这发生在应用程序级别(与基本 HTTP 身份验证中的框架或应用服务器级别相比)。
关于authentication - 微服务——如何解决安全和用户认证？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32574103/