当前位置:   article > 正文

微服务应用安全——Security

微服务应用安全——security

微服务应用安全——Security

对于业务应用安全,主要考虑两方面:一方面是保障只有认证的用户才可以访问应用,也就是用户认证;另一方面就是要保障访问者只有拥有足够的权限才可以访问某个资源,也就是用户鉴权。

见SecurityConfig,在用户鉴权的configure方法中,antMatchers的命名来源于Java早期的一个构建工具Ant,用于路径匹配,在这里可以使用通配符也可以使用逗号隔开多个路径。


10.2 微服务安全

如何提供细粒度的安全管控方案?

在进行单体架构应用开发时最常使用的安全管理机制就是基于用户会话(Session)的认证,用户登录成功后,服务器就会将用户相关数据及权限信息存储到Session中。通常Session会直接保存在应用服务器中,仅将Session的ID返回到客户端,并存储在浏览器的Cookie中(对于Java应用来说就是jsessionid),当下次访问时就可以通过该ID获取到相应的会话信息。当使用服务器集群时,可以通过Session复制或Session粘滞的方法来保障服务器可以获取到相应的Session数据。

1.单点登录(SSO)方案

单击登录方案是最常见的解决方案,但单点登录需要每个与用户交互的服务都必须与认证服务进行通信,这不但会造成重复,也会产生大量琐碎的网络流量;

2.分布式会话(Session)方案

通过将用户会话信息存储在共享存储中,如Redis,并使用用户会话的ID作为key来实现分布式哈希映射。当用户访问微服务时,会话数据就可以从共享存储中获取。该解决方案在高可用和扩展方面都很好,但是由于会话信息保存在共享存储中,所以需要一定的保护机制保护数据安全,因此在具体的实现中会具有比较高的复杂度

3.客户端令牌(Token)方案

令牌由客户端生成,并由认证服务器签名。在令牌中会包含足够的信息,客户端在请求时会将令牌附加在请求上,从而为各个微服务提供用户身份数据。此方案解决了分布式会话方案的安全性问题,但如何及时注销用户认证信息则是一个大问题,虽然可以使用短期令牌并频繁地与认证服务器进行校验,但并不可以彻底解决。JWT(JSONWeb Tokens)是非常出名的客户端令牌解决方案,它足够简单,并且对各种环境支持程度也比较高。

4.客户端令牌与API网关结合

通过在微服务架构中实施API网关,可以将原始的客户端令牌转换为内部会话令牌。一方面可以有效地隐藏微服务,另一方面通过API网关的统一入口可以实现令牌的注销处理

第二个方案:分布式Session方案中要求开发者能够将用户会话信息单独拎出来进行集中管理。业界比较成熟的开源项目有Spring Session,其使用Redis数据库或缓存机制来实现Session存储,并通过过滤器实现Session数据的自动加载。

基于令牌认证通常包含下面几层含义:

·令牌是认证用户信息的集合,而不仅仅是一个无意义的ID。

·在令牌中已经包含足够多的信息,验证令牌就可以完成用户身份的校验,从而减轻了因为用户验证需要检索数据库的压力,提升了系统性能。

·因为令牌是需要服务器进行签名发放的,所以如果令牌通过解码认证,我们就可以认为该令牌所包含的信息是合法有效的。

·服务器会通过HTTP头部中的Authorization获取令牌信息并进行检查,并不需要在服务器端存储任何信息。

·通过服务器对令牌的检查机制,可以将基于令牌的认证使用在基于浏览器的客户端和移动设备的App或是第三方应用上。

·可以支持跨程序调用。基于Cookie是不允许垮域访问的,而令牌则不存在这个问题。

综上:可以通过验证令牌来完成用户身份的校验。基于令牌的这个优点,像T微信、支付宝、微博及GitHub等,都推出了基于令牌的认证服务,用于访问所开放的API及单点登录。接下来将重点介绍基于令牌认证方案中的OAuth 2.0和JWT。


10.3 基于OAuth 2.0的认证

OAuth是一个开放的、安全的用户认证协议,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源,而无须将用户名和登录口令提供给第三方应用。授权的第三方应用只能在特定的时段内访问特定的资源,而非所有内容。每次授权的令牌只能针对一个第三方应用,因此可以认为OAuth是一个非常安全的用户认证/授权协议。

OAuth 2.0对认证流程进行了简化,更加关注客户端开发者的简易性,并为Web应用、桌面应用、手机App等提供专门的认证流程。但OAuth 2.0并不向下兼容OAuth 1.0。

基于OAuth 2.0的用户认证具有以下优点。

简单:安全:并不涉及用户密钥等信息 。开放:OAuth 2.0只是一个用户认证安全协议,所以任何服务提供商都可以基于该协议来实现,任何软件开发商都可以使用该协议完成用户认证流程。

10.3.1 OAuth 2.0授权流程

image-20200513144654603

(1)用户打开客户端以后,客户端要求用户给予授权。(2)用

声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号