微服务架构中的单点登录 [英] Single Sign-On in Microservice Architecture
问题描述
我想设计一个绿色领域的项目，它将有几个服务（服务数据）和网络应用程序（服务HTML）。我已经阅读了有关微服务，他们看起来很适合。
I'm trying to design a green-field project that will have several services (serving data) and web-applications (serving HTML). I've read about microservices and they look like good fit.
我仍然有的问题是如何实现SSO。我想让用户验证一次，并且可以访问所有不同的服务和应用程序。
The problem I still have is how to implement SSO. I want the user to authenticate once and have access to all the different services and applications.
我可以想到几种方法：
-
添加身份服务和应用程序。任何具有受保护资源的服务都将与身份服务通信，以确保其具有的凭据有效。
Add Identity service and application. Any service that has protected resources will talk to the Identity service to make sure the credentials it has are valid. If they are not it will redirect the user for authentication.
使用网络标准（如OpenID），让每个服务处理自己的身份。这意味着用户必须单独授权每个服务/应用程序，但之后它将是SSO。
Use a web-standard such as OpenID and have each service handle it own identities. This means the user will have to authorize individually each service/application but after that it will be SSO.
我们很乐意听到其他的想法。
I'll be happy to hear other ideas. If a specific PaaS (such as Heroku) has a proprietary solution that would also be acceptable.
推荐答案
在实现微服务架构的同时，我以前的工作，我们决定最好的方法是与＃1，添加身份服务和授权通过它的服务访问。在我们的例子中，这是用令牌完成的。如果请求带有授权令牌，那么我们可以使用身份服务来验证令牌，如果它是用户与服务的会话中的第一个调用。一旦令牌已经被验证，则它被保存在会话中，因此用户会话中的后续呼叫不必进行附加呼叫。
While implementing a microservice architecture at my previous job we decided the best approach was in alignment with #1, Add identity service and authorize service access through it. In our case this was done with tokens. If a request came with an authorization token then we could verify that token with the identity service if it was the first call in the user's session with the service. Once the token had been validated then it was saved in the session so subsequent calls in the user's session did not have to make the additional call. You can also create a scheduled job if tokens need to be refreshed in that session.
在这种情况下，我们使用OAuth 2.0端点进行身份验证，并将令牌添加到了用于调用我们网域的HTTP标头。所有的服务都是从该域中路由的，所以我们可以从HTTP头获取令牌。由于我们都是同一个应用程式生态系统的一部分，因此初始的OAuth 2.0授权会列出使用者授予其帐户权限的应用程式服务。
In this situation we were authenticating with an OAuth 2.0 endpoint and the token was added to the HTTP header for calls to our domain. All of the services were routed from that domain so we could get the token from the HTTP header. Since we were all part of the same application ecosystem, the initial OAuth 2.0 authorization would list the application services that the user would be giving permission to for their account.
这种方法是身份服务将提供将被添加到HTTP请求过滤器链并且处理对服务的授权过程的代理客户端库。该服务将被配置为从身份服务使用代理客户端库。因为我们使用Dropwizard这个代理将成为一个Dropwizard模块引导过滤器进入正在运行的服务进程。这允许对身份服务的更新，还有一个免费的客户端更新，只要接口没有显着变化，依赖服务就很容易消费。
An addition to this approach was that the identity service would provide the proxy client library which would be added to the HTTP request filter chain and handle the authorization process to the service. The service would be configured to consume the proxy client library from the identity service. Since we were using Dropwizard this proxy would become a Dropwizard Module bootstrapping the filter into the running service process. This allowed for updates to the identity service that also had a complimentary client side update to be easily consumed by dependent services as long as the interface did not change significantly.
我们的部署架构分布在AWS Virtual Private Cloud（VPC）和我们自己公司的数据中心。 OAuth 2.0身份验证服务位于公司的数据中心，而我们的所有应用程序服务都部署到AWS VPC。
Our deployment architecture was spread across AWS Virtual Private Cloud (VPC) and our own company's data centers. The OAuth 2.0 authentication service was located in the company's data center while all of our application services were deployed to AWS VPC.
我希望我们采用的方法有助于您的决定。如有任何其他问题，请与我们联络。
I hope the approach we took is helpful to your decision. Let me know if you have any other questions.
这篇关于微服务架构中的单点登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
