微服务系统中的认证策略

软件安全本身就是个很复杂的问题,由于微服务系统中的每个服务都要处理安全问题,所以在微服务场景下会更复杂。David Borsos在最近的伦敦微服务大会上作了相关内容的演讲,并评估了四种面向微服务系统的身份验证方案。

在传统的单体架构中,单个服务保存所有的用户数据,可以校验用户,并在认证成功后创建HTTP会话。在微服务架构中,用户是在和服务集合交互,每个服务都有可能需要知道请求的用户是谁。一种朴素的解决方案是在微服务系统中应用与单体系统中相同的模式,但是问题就在于如何让所有的服务访问用户的数据。解决这个问题大致两个思路:若使用共享用户数据库时,更新数据库表会成为一个难题,因为所有服务必须同时升级以便能够对接修改后的表结构;若将相同的数据分发给所有服务时,当某个用户已经被认证,如何让每个服务知晓这个状态是一个问题。

Borsos指出,单点登录(SSO)方案可能看起来是一个好主意,但这意味着每个面向用户的服务都必须与认证服务交互,这会产生大量非常琐碎的网络流量,同时这个方案实现起来也相当复杂 。 在其他方面,选择SSO方案安全性会很好,用户登录状态是不透明的,可防止攻击者从状态中推断任何有用的信息。

分布式会话方案,原理主要是将关于用户认证的信息存储在共享存储中,且通常由用户会话作为key来实现的简单分布式哈希映射。 当用户访问微服务时,用户数据可以从共享存储中获取。 该解决方案的另一个优点是用户登录状态是不透明的。 当使用分布式数据库时,它也是一个高度可用且可扩展的解决方案。 这种方案的缺点在于共享存储需要一定保护机制,因此需要通过安全链接来访问,这时解决方案的实现就通常具有相当高的复杂性了。

客户端令牌方案, 此令牌在客户端生成,由身份验证服务进行签名,并且必须包含足够的信息,以便可以在所有微服务中建立用户身份。 令牌会附加到每个请求上,为微服务提供用户身份验证。 这种解决方案的安全性相对较好,但身份验证注销是一个大问题, 缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。 对于客户端令牌的编码方案,Borsos更喜欢使用JSON Web Tokens(JWT),它足够简单且库支持程度也比较好。

客户端令牌与API网关结合,这个方案意味着所有请求都通过网关,从而有效地隐藏了微服务。 在请求时,网关将原始用户令牌转换为内部会话ID令牌。 在这种情况下,注销就不是问题,因为网关可以在注销时撤销用户的令牌。 这种方案虽然库支持程度比较好,但实现起来还是可能很复杂。

Borsos建议使用客户端令牌(使用JWT)和API网关结合的方案,因为这个方案通常使用起来比较容易,且性能也不错。 SSO方案虽然能满足需求,但他认为还是应该避免使用。若分布式会话方案所需要的相关技术已经应用在你的场景上,那么这个方案也是比较有趣的。他同时强调在选择解决方案时应着重考虑注销的重要性。

明年的伦敦微服务大会定于2017年11月6日-7日举行。

查看英文原文:Authentication Strategies in Microservices Systems



感谢张卫滨对本文的审校。

http://www.infoq.com/cn/news/2016/12/microservices-authentication

时间: 2024-11-06 12:01:41

微服务系统中的认证策略的相关文章

如何分析、调试微服务系统的故障?

基于研究论文<Fault Analysis and Debugging of Microservice Systems: Industrial Survey, Benchmark System, and Empirical Study>(作者:周翔.彭鑫.谢涛.孙军.冀超.李文海.丁丹)形成本文.该论文由复旦大学计算机科学技术学院彭鑫教授领导的智能化软件开发 CodeWisdom 团队与北京大学谢涛教授.新加坡管理大学孙军副教授合作完成,并被评选为软件工程领域的国际旗帜期刊.CCF A 类期刊

SpringCloud(9)使用Spring Cloud OAuth2保护微服务系统

一.简介 OAth2是一个标准的授权协议. 在认证与授权的过程中,主要包含以下3种角色. 服务提供方 Authorization Server. 资源持有者 Resource Server. 客户端 Client. OAuth2的认证流程如图所示,具体如下. (1)用户(资源持有者)打开客户端 ,客户端询问用户授权. (2)用户同意授权. (3)客户端向授权服务器申请授权. (4)授权服务器对客户端进行认证,也包括用户信息的认证,认证成功后授权给予令牌. (5)客户端获取令牌后,携带令牌向资源服

微服务架构中APIGateway原理

背景 我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用. 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中,举个例子. 在一个电商系统中,查看一个商品详情页,这个商品详情页包含商品的标题,价格,库存,评论等,这些数据对于后端

用Spring Cloud OAuth2保护微服务系统

一.简介# OAth2是一个标准的授权协议. 在认证与授权的过程中,主要包含以下3种角色. 服务提供方 Authorization Server. 资源持有者 Resource Server. 客户端 Client. OAuth2的认证流程如图所示,具体如下. (1)用户(资源持有者)打开客户端 ,客户端询问用户授权. (2)用户同意授权. (3)客户端向授权服务器申请授权. (4)授权服务器对客户端进行认证,也包括用户信息的认证,认证成功后授权给予令牌. (5)客户端获取令牌后,携带令牌向资源

微服务开发中的数据架构设计

本文来自作者 陈伟荣 在 GitChat 分享的文章[微服务开发中的数据架构设计] 前言 微服务是当前非常流行的技术框架,通过服务的小型化.原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合.业务的灵活调整组合以及系统的高可用性.为业务创新和业务持续提供了一个良好的基础平台.本文分享在这种技术架构下的数据架构的设计思想以及设计要点,本文包括下面若干内容. 微服务技术框架中的多层数据架构设计 数据架构设计中的要点 要点1:数据易用性 要点2:主.副数据及数据解耦 要点3:分库分表

Spring Boot + Spring Cloud 构建微服务系统(七):API服务网关(Zuul)

技术背景 前面我们通过Ribbon或Feign实现了微服务之间的调用和负载均衡,那我们的各种微服务又要如何提供给外部应用调用呢. 当然,因为是REST API接口,外部客户端直接调用各个微服务是没有问题的,但出于种种原因,这并不是一个好的选择. 让客户端直接与各个微服务通讯,会有以下几个问题: 客户端会多次请求不同的微服务,增加了客户端的复杂性. 存在跨域请求,在一定场景下处理会变得相对比较复杂. 实现认证复杂,每个微服务都需要独立认证. 难以重构,项目迭代可能导致微服务重新划分.如果客户端直接

微服务架构中整合网关、权限服务

前言:之前的文章有讲过微服务的权限系列和网关实现,都是孤立存在,本文将整合后端服务与网关.权限系统.安全权限部分的实现还讲解了基于前置验证的方式实现,但是由于与业务联系比较紧密,没有具体的示例.业务权限与业务联系非常密切,本次的整合项目将会把这部分的操作权限校验实现基于具体的业务服务. 1. 前文回顾与整合设计 在认证鉴权与API权限控制在微服务架构中的设计与实现系列文章中,讲解了在微服务架构中Auth系统的授权认证和鉴权.在微服务网关中,讲解了基于netflix-zuul组件实现的微服务网关.

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析 说明:Java生鲜电商平台中,由于服务进行了拆分,很多的业务服务导致了请求的网络延迟与性能消耗,对应的这些问题,我们应该如何进行网络请求的优化与处理呢? 到底有没有一些好的建议与方案呢? 下面这个文章将揭晓上面的问题,让你对SpringCloud微服务网络请求性能有一个全新的认识. 目录简介 01.网络请求异常分类 02.开发中注意问题 03.原始的处理方式 04.如何减少代码耦合性 05.异常统一处理步骤 06

在微服务系统开发部署中使用Azure RBAC自定义角色

Azure的官方文档介绍了如何创建用于Azure基于角色的访问控制的自定义角色(RBAC Role). 我们也可以根据同样的原理把RBAC细粒度资源管理运用于微服务产品的开发部署中.(https://www.azure.cn/documentation/articles/role-based-access-control-custom-roles/) 由于快速变化的业务需求,微服务的系统架构设计经常会发生变化,开发团队常常需要增加一个新的微服务,降级一个旧版本的微服务,把一个微服务分隔成2个..