微服务体系结构中的单点登录

Question

我正试图设计一个将有多个服务（服务数据）和Web应用程序（服务HTML）的绿色领域项目。我读过关于微服务的内容，看起来很合适。

我还有的问题是如何实现SSO。我希望用户进行一次认证，并有权访问所有不同的服务和应用程序。

我能想到的几种方法：

1. 添加身份服务和应用。任何具有受保护资源的服务都将与Identity服务通信，以确保其拥有的凭证有效。如果他们不是，它会重定向用户进行身份验证。

2. 使用网络标准，如OpenID，并让每个服务处理它自己的身份。这意味着用户将不得不单独授权每个服务/应用程序，但在此之后它将成为SSO。

我很乐意听到其他想法。如果一个特定的PaaS（比如Heroku）拥有一个专有的解决方案，那也是可以接受的。

Answer 1

在我以前的工作中实现微服务架构时，我们决定采用最佳方法与＃1一致，添加身份服务并通过它授权服务访问权限。在我们的例子中，这是用令牌完成的。如果请求带有授权令牌，那么我们可以使用身份服务验证该令牌，如果它是用户与服务的会话中的第一个呼叫。一旦令牌被验证，它就被保存在会话中，以便用户会话中的后续呼叫不必进行额外的呼叫。如果令牌需要在该会话中刷新，您还可以创建预定作业。

在这种情况下，我们使用OAuth 2.0端点进行身份验证，并将令牌添加到HTTP标头以调用我们的域。所有的服务都从该域中路由，所以我们可以从HTTP头获取令牌。由于我们都是同一应用程序生态系统的一部分，因此最初的OAuth 2.0授权将列出用户将为其帐户授予的应用程序服务。

此方法的一个补充是身份服务将提供代理客户端库，它将被添加到HTTP请求过滤器链并处理授权过程到服务。该服务将被配置为使用来自身份服务的代理客户端库。由于我们使用的是Dropwizard，该代理将成为一个Dropwizard模块，将过滤器引导到正在运行的服务进程中。这允许对身份服务进行更新，只要接口没有显着变化，也可以通过相关服务轻松使用免费的客户端更新。

我们的部署架构遍布AWS Virtual Private Cloud（VPC）和我们自己公司的数据中心。 OAuth 2.0身份验证服务位于公司的数据中心，而我们的所有应用程序服务均已部署到AWS VPC。

我希望我们采取的方法有助于您的决定。如果您有任何其他问题，请告诉我。

Answer 2

Chris Sterling解释了上面的标准认证实践，这是绝对有道理的。我只是想出于一些实际的原因在这里再想一想。

我们实施了认证服务和多个其他依赖auth服务器的微服务来授权资源。在某些时候，由于往返认证服务器的次数过多，我们遇到了性能问题，随着微服务数量的增加，我们对auth服务器也存在可扩展性问题。我们稍微改变了架构以避免过多的往返行程。

Auth服务器将只与证书联系一次，它将基于私钥生成令牌。对应的公钥将被安装在每个客户端（微服务服务器）中，这将能够验证身份验证密钥与无联系身份验证服务器。密钥包含生成的时间以及安装在微服务中的客户端实用程序也会有效。尽管这不是标准的实现，但是我们对这个模型非常成功，特别是当所有的微服务都在内部托管时。