微服务——如何解决安全和用户认证？答案

【问题标题】：Microservices - how to solve security and user authentication?微服务——如何解决安全和用户认证？
【发布时间】：2015-12-11 00:05:33
【问题描述】：

关于微服务架构的讨论很多。我所缺少的——或者我可能还不明白的是，如何解决安全和用户身份验证问题？

例如：我开发了一个微服务，它为工作流引擎提供了一个 Rest Service 接口。该引擎基于 JEE，并在 GlassFish 或 Wildfly 等应用服务器上运行。工作流引擎的核心概念之一是，每个调用都以用户为中心。这意味着根据当前用户的角色和访问级别，工作流引擎会产生单独的结果（例如，以用户为中心的任务列表或处理取决于用户在流程中的角色的打开任务）。

在我看来，因此无法从任何地方访问服务。例如，如果有人计划实现一个基于 Ajax 的现代 JavaScript 应用程序，该应用程序应该使用工作流微服务，那么存在两个问题：

1) 为避免 JavaScript/Ajax 的跨脚本问题，JavaScript Web 应用程序需要部署在与微服务运行相同的域下

2) 如果微服务强制进行用户身份验证（在我的场景中就是这种情况），则应用程序需要提供透明的身份验证机制。

如果客户端需要访问多个以用户为中心的微服务来强制进行用户身份验证，情况就会变得更加复杂。我总是最终得到一个架构，其中所有服务和客户端应用程序都运行在同一域下的同一应用程序服务器上。

如何解决这些问题？这种架构的最佳实践是什么？

【问题讨论】：

我不确定跨脚本是否是对第一个问题的正确描述。我的意思是跨域资源共享 (CORS)。

标签： authentication jakarta-ee microservices

【解决方案1】：

简答：检查 OAUTH，并管理每个需要访问其他微服务的微服务中的凭据缓存。我所说的“管理”是指注意安全性。特别注意谁可以访问这些凭据并让网络拓扑成为您的朋友。创建一个 DMZ 层和其他反映微服务依赖关系图的内部层。

答案很长，请继续阅读。您的问题是一个很好的问题，因为尽管您的问题经常出现，但没有简单的灵丹妙药可以满足您的需求。

与我目前看到的与微服务相关的所有内容一样，没有什么是真正新鲜的。每当您需要让分布式系统代表某个用户执行操作时，您都需要分布式凭据来启用此类解决方案。自大型机时代以来就是如此。没有办法违反。

Auto SSH 在某种意义上就是这样的东西。也许这听起来像是描述简单事物的一种美化方式，但最终，它使一台机器中的进程能够使用另一台机器中的服务。

例如，在网格世界中，Globus Toolkit 使用以下内容作为其distributed security 的基础：

X.509 证书；
MyProxy - 管理凭据存储库并帮助您定义一系列证书颁发机构，直至找到根证书颁发机构，默认情况下应受信任；
OpenSSH 的扩展，它是 Linux 发行版事实上的标准 SSH 实现。

OAUTH 或许正是您所需要的。这是一种提供额外限制的授权方式。例如，假设某个用户对某个服务具有读写权限。当您发出 OAUTH 授权时，您不一定将全部用户权力授予第三方。您只能授予读取权限。

另一个答案中提到的 CORS 在最终客户端（通常是 Web 浏览器）需要跨网站单点登录时很有用。但似乎您的问题更接近于一个集群，其中有许多由您管理的微服务。不过，您可以利用 Grid 领域开发的解决方案来确保跨站点分布的集群的安全性（例如，出于高可用性的原因）。

完全安全是无法实现的。因此，如果凭据永远有效，或者如果您没有足够小心地将它们保密，那么所有这些都是没有用的。为此，我建议使用层对网络进行分区。每一层都有不同程度的保密性和对外暴露程度。

如果您不希望负担允许 OAUTH 所需的基础设施，您可以使用基本 HTTP 或创建自己的令牌。

使用basic HTTP authentication时，客户端需要在每个请求上发送凭据，因此无需在服务器端保持会话状态以进行授权。

如果您想创建自己的机制，请更改您的登录请求，以便返回一个令牌作为对成功登录的响应。具有相同令牌的后续请求将充当基本 HTTP 身份验证，其优势在于这发生在应用程序级别（与基本 HTTP 身份验证中的框架或应用服务器级别相比）。

【讨论】：

感谢我们的回答。我想现在我明白 CORS 是一个小问题，看起来我可以通过扩展我的 JAX-RS 服务 API 轻松解决这个问题。问题 2) 看起来有点复杂。因为我的开源项目（Imixs-Workflow）应该针对不同的用例开放。过去 JAAS 是我在 JEE 堆栈上炒的，安全性易于配置且非常灵活。但是 OAUTH 对我来说看起来很复杂。我不想仅仅因为我想允许外部客户端使用微服务架构访问我的工作流解决方案而实现身份验证服务器。
我明白了。阅读最后一条消息后，CORS 似乎更不能真正解决您的问题，因为您项目中的 REST 接口不仅限于 Web 浏览器中的 Javascript 客户端。我同意 JAAS 很棒并且在 Java 领域中可以完美运行，但是当您使用开放标准时，情况就不同了。如果您不想使用 OAUTH，那么另一种解决方案是实现自己的机制来生成令牌。我会相应地更新我的答案。
我阅读了有关基于令牌的身份验证的更多信息，现在我越来越相信 OAUTH 是正确的解决方案。我需要一个适合我的 GlassFish、WildFly JEE 服务器环境的 OAUTH 服务器。
太棒了。我认为您的举动是正确的，尤其是考虑到您的项目是 FOSS。
@Ralph，很抱歉指出这一点，但我不介意用绿色的东西表示对我的回答的赞赏。 :)

【解决方案2】：

您的问题是关于两个独立的问题。

通过实现CORS 可以轻松解决从其他来源访问您的服务的问题。对于非浏览器客户端，跨域根本不是问题。

关于服务认证的第二个问题通常使用token based authentication 来解决。

任何一个微服务的调用者都会从授权服务器或 STS 获取该特定服务的访问令牌。

您的客户端通过已建立的会话 (cookie) 或通过随请求发送有效令牌向授权服务器或 STS 进行身份验证。

【讨论】：