微服务架构中的单点登录

Question

我正在尝试设计一个绿色领域项目,该项目将包含多个服务(服务数据)和Web应用程序(提供HTML).我读过微服务,看起来很合适.

我还有的问题是如何实现SSO.我希望用户进行一次身份验证,并可以访问所有不同的服务和应用程序.

我可以想到几种方法:

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

2. 使用诸如OpenID之类的Web标准,并让每个服务处理它自己的身份.这意味着用户必须单独授权每个服务/应用程序,但之后它将是SSO.

我很乐意听到其他想法.如果特定PaaS(例如Heroku)具有也可接受的专有解决方案.

Answer 1

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

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

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

我们的部署架构分布在AWS虚拟私有云(VPC)和我们公司的数据中心.OAuth 2.0身份验证服务位于公司的数据中心,而我们的所有应用程序服务都部署到AWS VPC.

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

Answer 2

克里斯斯特林解释了上面的标准认证实践,这是绝对有意义的.出于某些实际原因,我只想在此处再考虑一下.

我们实现了身份验证服务和依赖auth服务器的多个其他微服务来授权资源.由于往返认证服务器的次数过多,我们在某些时候遇到了性能问题,随着微服务数量的增加,我们也遇到了auth服务器的可扩展性问题.我们改变了架构,避免了太多的往返.

Auth服务器仅与凭证联系一次,它将根据私钥生成令牌.相应的公钥将安装在每个客户端(微服务服务器)中,该客户端将能够通过联系auth服务器来验证身份验证密钥.密钥包含生成的时间,并且在微服务中安装的客户端实用程序也将有效.尽管它不是标准实现,但我们在此模型上取得了相当不错的成功,特别是当所有微服务都在内部托管时.