微服务系统中的认证策略

软件安全本身就是个很复杂的问题,由于微服务系统中的每个服务都要处理安全问题,所以在微服务场景下会更复杂。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-08-07 06:00:05

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

认证鉴权与API权限控制在微服务架构中的设计与实现(一)

作者: [Aoho's Blog] 引言: 本文系<认证鉴权与API权限控制在微服务架构中的设计与实现>系列的第一篇,本系列预计四篇文章讲解微服务下的认证鉴权与API权限控制的实现. 1. 背景 最近在做权限相关服务的开发,在系统微服务化后,原有的单体应用是基于session的安全权限方式,不能满足现有的微服务架构的认证与鉴权需求.微服务架构下,一个应用会被拆分成若干个微应用,每个微应用都需要对访问进行鉴权,每个微应用都需要明确当前访问用户以及其权限.尤其当访问来源不只是浏览器,还包括其他服务

微服务架构中API网关的角色

[编者的话]本文主要讲述了Mashape的首席技术执行官Palladino对API网关的详细介绍,以及API网关在微服务中所起的作用,同时介绍了Mashape的一款开源API网关Kong. 本文讲的是微服务架构中API网关的角色API网关提供商Mashape的首席技术执行官Marco Palladino预测,尽管它们在命名方面存在差异,但新出现的服务网格并不完全不同于API网关,两者之间的相似性会随着时间的推移而不断增长. Palladino指出,实际上这两种技术提供的功能很相似.API网关,比

使用Spring Boot日志框架在已有的微服务代码中添加日志功能

引言:我们需要在已有的微服务代码中添加日志功能,用于输出需要关注的内容,这是最平常的技术需求了.由于我们的微服务代码是基于SpringBoot开发的,那么问题就转换为如何在Spring Boot应用程序中输出相应的日志. 在传统Java应用程序中,我们一般会使用类似Log4j这样的日志框架来输出日志,而不是直接在代码中通过System.out.println()来输出日志.为什么要这么做呢?原因有两点.其一,我们希望日志能输出到文件中,而不是输出到应用程序的控制台中,这样更加容易收集和分析.其二

微服务架构中模块划分和服务识别

最近在进行微服务架构的交流和讨论中,除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务API接口的识别和定义问题,因此这篇文章将重点谈下微服务架构实践过程中的微服务模块划分和服务识别. 首先我们还是再总结在在跨系统间的接口集成中服务的识别和定义方法,可以总结为: 1. 基于流程架构和业务架构,从跨系统交互流程出发,分析业务交互接口点,识别关键的业务服务能力. 2. 基于数据架构和主数据建模分析,识别关键的数据服务能力. 3. 基于技术架构和共性平台层技术组件的分析和

微服务转型,雪崩效应是绕不过的一道坎

1.星火燎原 1.1农民眼中的微服务 本文讲的是微服务转型,雪崩效应是绕不过的一道坎,近年来,微服务就象一把燎原的大火,窜了出来并在整个技术社区烧了起来,微服务架构被认为是IT软件服务化架构演进的目标.为什么微服务这么火,微服务能给企业带来什么价值? 1.1.1 以种植农作物的思想来理解微服务 我们以耕种为例来看如何充分利用一块田地的: 先在地里种植了一排排玉米: 后来发现玉米脚下空地可以利用,再间隔一段距离再种上豆角,豆角长大后顺着玉米杆往上爬,最后紧紧地缠绕在玉米杆上: 再后来发现每排玉米之

产品级微服务的八大原则

本文讲的是产品级微服务的八大原则[编者的话]虽然微服务架构给开发者带来很大的自由,但是确保服务的可用性却要求对微服务进行很好的架构,运维以及组织标准. O'Reilly这本免费的电子书<Microservices in Production>介绍了微服务标准化的挑战,以可用性作为微服务标准化的目标,提出了八个标准化微服务的原则,包括在整个工程组织中实现production-readiness标准的策略. 这本书的作者是 Susan J. Fowler,Uber 的 SRE(site relia

微服务与安全

"我们都知道洗手在预防疾病传播上的重要性,但是在面对应用安全问题时,类似的行为却变成了马后炮.我们已经掌握了在开发工作流中加入测试的做法,但是对于安全问题却常假定稍后会有其他的人去解决."这是Sam Newman近期在伦敦微服务大会的主题演讲中所提出的观点.他的演讲内容围绕微服务环境中的安全问题而展开. Newman当前供职于Atomist,他认为各个微服务构成了一种六边形的形态,其中每种微服务的命名是与它们的业务职责相对应的.这些微服务具备自治能力.Newman特别指出,这些微服务的

再谈Docker,微服务的场景化应用

看过<超能陆战队>的朋友可能仍然对于电影中的男主角介绍和演示自己发明的微型机器人的场景记忆犹新. "它"看起来只是一跟带有磁性的小小的金属部件.但是它是一个独立的个体,自己能够独立的大脑,同时,和同伴之间有相互的接口你行链接.能够通讯.能够随意的组合成任意功能的物体. 通过类比,我们很容易由硬件领域想到软件领域.譬如软件系统的架构,一直都是伴随着几种主流的模式,集中式,分布式以及最近才开始流行起来的"微服务". 滨田宏发明的微型机器人,其实和微服务的思想

高速换轮:Uber如何用微服务重构工程系统?

几个月前,我们讨论过Uber关于放弃它单一整体的代码库,而支持一种模块化的灵活的微服务结构.自那时候以来,我们已经花费了数千个小时,使用多种语言和多种不同的框架来扩展Uber的微服务(数以百计)生态系统.这种持续的重构是一个巨大的挑战,因此,我们趁机在Uber的微服务中采用了一套新的技术.通过一个技术栈和一套符合SOA迁移的标准,我们已经大大简化了整个服务的开发.   开始一个新服务    在一个快速发展工程组织中,我们可能很难跟踪所有正在进行的工作.这种增长需要一个流程来防止不同团队之间的重复