微服务-如何解决安全和用户身份验证问题？

Question

微服务-如何解决安全和用户身份验证问题？

3

有很多关于微服务架构的讨论。我想知道的是，如何解决安全和用户身份验证问题？例如：我开发了一个微服务，为工作流引擎提供Rest服务接口。该引擎基于JEE并运行在应用服务器上，如GlassFish或Wildfly。工作流引擎的核心概念之一是每个调用都是以用户为中心的。这意味着根据当前用户的角色和访问级别，工作流引擎会生成个性化结果（例如，以用户为中心的任务列表或处理依赖于用户在过程中的角色的待处理任务）。因此，某个服务不是从任何地方都可以访问的。例如，如果有人计划实现一个现代Ajax基于JavaScript的应用程序，该应用程序应该使用工作流微服务，则会出现两个问题：

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

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

如果客户端需要访问多个强制进行用户身份验证的以用户为中心的微服务，则情况变得更加复杂。最终，我总是得到这样一种架构：所有服务和客户端应用程序都在同一应用服务器下运行，位于相同的域下。如何解决这些问题？对于这样的架构，最佳实践是什么？

- Ralph

我不确定跨脚本是否是第一个问题的正确描述。我的意思是跨源资源共享（CORS）。 - Ralph

2个回答

3

您的问题涉及两个独立的问题。

通过实施CORS，可以轻松解决使您的服务从另一个来源可访问的问题。对于非浏览器客户端，跨域不是问题。

关于服务身份验证的第二个问题通常使用基于令牌的身份验证来解决。

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

您的客户端通过已建立的会话（cookie）或通过在请求中发送有效令牌进行与授权服务器或STS的身份验证。

- MvdD

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Akira · Accepted Answer

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

长话短说，继续阅读。您的问题很好，因为没有简单的银弹来解决您的问题，尽管您的问题相当常见。

与我迄今看到的所有与微服务相关的内容一样，没有什么是真正新的。每当您需要有分布式系统代表某个用户执行操作时，都需要分布式凭据才能启用此类解决方案。自大型机时代以来，这就是事实。没有违反这一点的方法。 Auto SSH 从某种意义上说也是这样一件事。也许它听起来像是描述某些简单东西的夸张方式，但最终，它使一个机器中的进程能够使用另一个机器中的服务。

在Grid世界中，例如Globus Toolkit，它使用以下内容作为基础的分布式安全性：

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

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

CORS（另一个答案中提到的）在需要跨网站单点登录的情况下非常有用，但似乎您的问题更接近于一个由您管理的包含多个微服务的集群。尽管如此，您仍可以利用Grid领域开发的解决方案来确保在跨站点分布的集群中实现安全性（例如出于高可用性原因）。

完全的安全是不可达成的。因此，如果凭据永久有效或者您没有足够的注意力将其保密，则所有这些都是无用的。为此，我建议使用分层对网络进行分区。每一层具有不同的机密度和暴露于外部世界的程度。

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

在使用基本HTTP身份验证时，客户端需要在每个请求上发送凭据，因此可以消除为了授权目的在服务器端保持会话状态的需要。

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