微服务系统中的认证策略

标签: 微服务 系统 认证 | 发表时间:2017-04-05 07:02 | 作者:wangkeheng
出处:http://www.iteye.com

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

 

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

 

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

 

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

 

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

 

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

 

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



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [微服务 系统 认证] 推荐:

微服务系统中的认证策略

- - 企业架构 - ITeye博客
软件安全本身就是个很复杂的问题,由于微服务系统中的每个服务都要处理安全问题,所以在微服务场景下会更复杂. David Borsos在最近的伦敦微服务大会上作了相关内容的演讲,并评估了四种面向微服务系统的身份验证方案. 在传统的单体架构中,单个服务保存所有的用户数据,可以校验用户,并在认证成功后创建HTTP会话.

微服务架构统一安全认证设计与实践

- - DockOne.io
【编者的话】当企业应用系统逐渐增多后,每个系统单独管理各自的用户数据容易形成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进. 当企业的互联网业务发展到一定规模,构建统一的标准化账户管理体系将是必不可少的,因为它是企业互联网云平台的重要基础设施,能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力,为企业带来诸如跨系统单点登录、第三方授权登录等基础能力,为构建开放平台和业务生态提供了必要条件.

微服务架构下的认证鉴权解决方案

- - 掘金 架构
我们来自字节跳动飞书商业应用研发部(Lark Business Applications),目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域. 我们关注的产品领域主要在企业经验管理软件上,包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统,也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统.

微服务架构:如何用十步解耦你的系统?

- - 掘金后端
耦合性,是对模块间关联程度的度量. 耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少. 模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系. 模块间联系越多,其耦合性越强,同时表明其独立性越差. 软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准.

一个基于Spring Cloud的微服务电商平台系统

- - 程序猿DD
年之计在于春,新年就要有新的打算,TJ君身边不少小伙伴都有点想在新的一年里开个网店的冲动,但是如何入手、如何开店都是个学问,需要好好研究,不过这也说明了电商行业的前景还是不错滴. 所以当TJ君今天留意到这个开源项目的时候,第一反应就是,可用. 说到mall4cloud,不得不先说下Mall4j. Mall4j是一个商用的提供多元化电商服务,满足企业多场景业务需求,为垂直行业提供专业的电商解决方案网站,提供多种成熟的电商配套服务,而mall4cloud则正是它的 开源版本.

全方面解析微服务架构下的统一身份认证和授权 - 知乎

- -
本文讨论基于微服务架构下的身份认证和用户授权的技术方案,在阅读之前,最好先熟悉并理解以下几个知识点:. 微服务架构相关概念:服务注册、服务发现、API 网关. 身份认证和用户授权:SSO、CAS、OAuth2、JWT. 文章在涉及到上述知识内容时,会附上参考链接. 当企业的应用系统逐渐增多后,每个系统单独管理各自的用户数据容易行成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进.

消息系统在微服务间通讯的数据一致性

- - 互联网 - ITeye博客
微服务是当下的热门话题,今天来聊下微服务中的一个敏感话题:如何保证微服务的数据一致性. 谈到分布式事务,就避免不了CAP理论. CAP理论是指对于一个分布式计算系统来说,不可能同时满足以下三点: . 一致性(Consistence) (等同于所有节点访问同一份最新的数据副本). 可用性(Availability)(对数据更新具备高可用性).

分布式系统下的认证与授权 (insights.thoughtworks.cn)

- - IT瘾-jianshu
在软件系统设计中,如何让应用能够在各种环境中安全高效的访问是个复杂的问题,这个问题的背后是一系列软件设计时需要考虑的架构安全问题: 架构安全性 | 凤凰架构. 认证:系统如何识别合法用户,也就是解决. 授权:系统在识别合法用户后,还需要解决. 凭证:系统如何保证它与用户之间的承诺是双方真实意图的体现,是准确、完整且不可抵赖的;.

解析微服务架构(一)单块架构系统以及其面临的挑战

- - 博客园_知识库
  多年来,我们一直在技术的浪潮中乘风破浪,扬帆奋进,寻找更优秀的方法来构建IT系统,也一直在积极的学习并观察先进的公司如何以不同的架构方式构建或者优化其IT系统,来积极应对市场的变化,迅速做出响应,从而为客户提供更多的价值.   微服务架构模式(Microservice Architect Pattern)是近两年在软件架构模式领域里出现的一个新名词.

基于支付系统场景的微服务架构的分布式事务解决方案

- - 研发管理 - ITeye博客
分布式系统架构中,分布式事务问题是一个绕不过去的挑战. 而微服务架构的流行,让分布式事问题日益突出. 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析. 如上图所示,假设三大参与平台(电商平台、支付平台、银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析:.