微服务 - 如何解决安全性和用户认证？ [英] Microservices - how to solve security and user authentication?

问题描述

有一个关于微服务架构的讨论很多。我所缺少的 - 或者什么，我还不明白的是，如何解决安全性和用户认证问题

There is a lot of discussion about microservice architecture. What I am missing - or maybe what I did not yet understand is, how to solve the issue of security and user authentication?

例如：我开发一个微服务提供REST服务接口，一个工作流引擎。该发动机是基于JEE和运行在比如GlassFish或Wildfly应用程序服务器。
其中一个工作流引擎的核心概念是，每次通话以用户为中心。这意味着根据当前用户的角色和访问级别的，工作流引擎产生个别结果（例如以用户为中心任务列表或处理取决于在该过程中的用户角色的开放任务）。

For example: I develop a microservice which provides a Rest Service interface to a workflow engine. The engine is based on JEE and runs on application servers like GlassFish or Wildfly. One of the core concepts of the workflow engine is, that each call is user centric. This means depending of the role and access level of the current user, the workflow engine produces individual results (e.g. a user-centric tasklist or processing an open task which depends on the users role in the process).

在我眼里，这样一个服务并不是来自世界各地访问。例如，如果有人计划实施应使用工作流程微服务现代化的基于Ajax的JavaScript应用有两个问题：

In my eyes, thus a service is not accessible from everywhere. For example if someone plans to implement a modern Ajax based JavaScript application which should use the workflow microservice there are two problems:

1），以避免从JavaScript / AJAX的跨脚本编写问题JavaScript的Web应用程序需要同一个域中运行微服务

1) to avoid the cross-scripting problem from JavaScript/Ajax the JavaScript Web application needs to be deployed under the same domain as the microservice runs

2）如果微服务强制用户认证（这是这种情况在我的情况下）的应用需要提供一种透明的认证机制。

2) if the microservice forces a user authentication (which is the case in my scenario) the application need to provide a transparent authentication mechanism.

如果客户端需要访问多个用户为中心的微服务迫使用户身份验证的情况变得更加复杂。
我总是最后，所有的服务和客户端应用程序相同的域下的同一个应用服务器上运行的架构。

The situation becomes more complex if the client need to access more than one user-centric microservices forcing user authentication. I always end up with an architecture where all services and the client application running on the same application server under the same domain.

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

How can these problems be solved? What is the best practice for such an architecture?

推荐答案

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

Short answer: check OAUTH, and manage caches of credentials in each microservice that needs to access other microservices. By "manage" I mean, be careful with security. Specially, mind who can access those credentials and let the network topology be your friend. Create a DMZ layer and other internal layers reflecting the dependency graph of your microservices.

长一点的回答，请继续阅读。你的问题是一个很好的，因为没有简单的银弹做你需要的东西，虽然你的问题是相当反复。

Long answer, keep reading. Your question is a good one because there is no simple silver bullet to do what you need although your problem is quite recurrent.

作为一切与我看到到目前为止微服务相关的，没有什么是真正的新。每当你需要有一个分布式系统代表某个用户做的事情，你需要分布式的凭证来实现这种解决方案。这是自大型机时代真的。有没有办法违反了

As with everything related with microservices that I saw so far, nothing is really new. Whenever you need to have a distributed system doing things on behalf of a certain user, you need distributed credentials to enable such solution. This is true since mainframe times. There is no way to violate that.

自动SSH 是，从某种意义上说，这样的事情。也许这听起来像一个华而不实的方式来描述简单的东西，但最后，它能够在一台机器的进程在另一台机器使用的服务。

Auto SSH is, in a sense, such a thing. Perhaps it may sound like a glorified way to describe something simple, but in the end, it enables processes in one machine to use services in another machine.

在网格世界， Globus工具箱，例如基于其的分布式安全使用下列内容：

In the Grid world, the Globus Toolkit, for instance, bases its distributed security using the following:

• X.509证书;


• MYPROXY - 管理凭证的存储库，并帮助您定义证书颁发机构的连锁高达找到根源之一，应该是默认信任的;


• 的OpenSSH的扩展，这对Linux发行版的事实上的标准SSH实现。

OAUTH 也许是你所需要的。它是一种提供授权有额外的限制。例如，假设某个用户具有读取和对某个服务写权限。当你发出OAuth授权你不一定充分用户的权力给第三方。你可以只给读访问。

OAUTH is perhaps what you need. It is a way provide authorization with extra restrictions. For instance, imagine that a certain user has read and write permission on a certain service. When you issue an OAUTH authorization you do not necessarily give full user powers to the third party. You may only give read access.

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

CORS, mentioned in another answer, is useful when the end client (typically a web browser) needs single-sign-on across web sites. But it seems that your problem is closer to a cluster in which you have many microservices that are managed by you. Nevertheless, you can take advantage of solutions developed by the Grid field to ensure security in a cluster distributed across sites (for high availability reasons, for instance).

完备的安全的东西达不到的。所以，这一切还是没有用的，如果凭据是永远有效，如果你不采取足够的照顾，让他们秘密收到任何他们。为了这样的目的，我会建议使用图层划分您的网络。每个层与不同程度的保密和暴露于外界。

Complete security is something unattainable. So all this is of no use if credentials are valid forever or if you do not take enough care to keep them secret to whatever received them. For such purpose, I would recommend partitioning your network using layers. Each layer with a different degree of secrecy and exposure to the outside world.

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

If you do not want the burden to have the required infrastructure to allow for OAUTH, you can either use basic HTTP or create your own tokens.

在使用基本的HTTP认证，客户端需要对每个请求发送凭据，因此无需保持会话国家在服务器端进行授权的目的。

When using basic HTTP authentication, the client needs to send credentials on each request, therefore eliminating the need to keep session state on the server side for the purpose of authorization.

如果你想创建自己的机制，那么改变你的登录请求，使得令牌作为响应返回到登录成功。具有同样的后续请求将作为与优势，这发生在应用层（与基本的HTTP验证框架或应用服务器级别对比）的基本HTTP验证。

If you want to create your own mechanism, then change your login requests such that a token is returned as the response to a successful login. Subsequent requests having the same token will act as the basic HTTP authentication with the advantage that this takes place at the application level (in contrast with the framework or app server level in basic HTTP authentication).

这篇关于微服务 - 如何解决安全性和用户认证？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！