http://wwwbuild.net/greatops/414179.html 原文地址
李文权
数人云资深售前工程师,致力于帮助客户进行实施部署,提供最适合的解决方案;之前在惠普工作5年,主要负责Openstack、Docker等云计算方面的项目开发;开源技术拥护者,热衷于IT技术交流和分享。
导语
我们首先从传统单体应用架构下的访问安全设计说起,然后,分析下现代微服务架构下,访问安全涉及的原则,接着,来看下目前常用的几种,微服务架构下的访问安全设计方案。最后,重点看下Spring Cloud微服务架构下,是如何解决访问安全这个问题的。
一、传统单体应用的访问安全设计
上面的示意图展示了单体应用的访问逻辑。用户通过客户端发出http或者https请求,经过负载均衡后,单体应用收到请求。接着经过auth层,进行身份验证和权限批准,这里,一般会有跟后端数据库的交互。
通过后,将请求分发到对应的功能逻辑层中去。完成相关操作后,返回结果给客户端。
传统单体应用的访问安全设计——原则
从以上分析可以看到,传统单体应用的访问安全设计原则为:
-
第一,每次的用户请求都需要验证是否安全,这里可以分两种情况:
-
一种是没有session的请求,需要经过几个步骤完成session化。一般为验证当前用户的credential,获取当前用户的identity,这两步都需要访问数据库等持久化对象来完成,最后一步是为当前可用创建session,返回给客户端后,启用该session。
-
另一种是有session的请求,只需验证请求中当前session的有效性,即可继续请求。
-
-
第二,用户的操作请求都在后端单个进程中执行完成,完全依赖后端调用方法的可靠性。一旦出错,应用是无法再次重复请求。
传统单体应用的访问安全设计——优势和注意点
小结: 传统单体应用由于设计相对简单单一,暴露给外界的入口相对较少,从而具有被攻击并造成危害性的可能小的优势。
也正是由于单体应用简单单一的特点,需要注意相关问题:
-
应用后端保存了所有的credential等敏感信息
-
一旦入侵了对这个应用的请求,就有可能拿到所有的保存在后端的信息
-
应用的每次操作一般都需要和数据库进行交互,造成数据库负载变高
二、微服务架构下,访问安全设计原则
先来看下这张典型的微服务设计架构图,如图所示,有以下几点特征:
-
每个服务只有权限去操作自己负责的那部分功能。
-
用户请求的身份验证和权限批准都由独立的gateway服务来保障
-
对外服务的LB层无法直接与提供业务服务的应用层进行访问
从上面的特征分析来看,想要给出一份访问安全设计的原则说明,就要看看微服务架构下,访问安全有哪些痛点,以下罗列了几点:
-
单点登录,即在微服务这种多独立服务的架构下,实现用户只需要登录一次就能访问所有相互信任的应用系统。
-
微服务架构下的应用一般都是无状态的,导致用户的请求每次都需要鉴权,可能引发Auth服务的性能瓶颈。
-
微服务架构下,每个组件都管理着各自的功能权限,这种细粒度的鉴权机制需要事先良好的规划。
-
微服务架构下,需要考虑到那些非浏览器端的客户请求,是否具有良好的可操作性。
根据实际情况,还有一些其他痛点,这里不再一一赘述,而这些痛点,就形成了我们在为微服务架构设计访问安全的原则。
三、微服务架构下,常用的访问安全设计方案
-
HTTP Basic Authentication + Independent Auth DB
-
HTTP Basic Authentication + Central Auth DB
-
API Tokens
-
SAML
这里列出4种,首先简单介绍下,然后一一叙述。
第一种,使用HTTP Basic Auth协议,加上独立的Auth数据库。
第二种,也是使用HTTP Basic Auth协议,跟第一种不同的是,使用集中式的Auth数据库
第三种,API Tokens协议,这种大家应该比较熟悉,很多公有服务(比如Github、Twitter等)的API都是用这种方式。
第四种,SAML,即Security Assertion Markup Language,翻译过来,是『安全声明标记语言』,它是基于XML的一种协议,企业内使用得较多。
下面一一做介绍。
1. 微服务常用访问安全设计方案——Basic Auth + Independent Auth DB
第一种,如上示意图所示,使用Basic Auth协议,配合每个服务自己都拥有存储Credential敏感数据的数据库(或者其他持久化仓库)。
简单介绍下Basic Auth协议,它是在用户的请求中添加一个Authorization消息头,这个消息头的值是一个固定格式:
Basic base64encode(username+“:”+password)
完整的消息头列子为:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic Auth协议基本上被所有流行的网页浏览器都支持。
这种方案的特点:
-
每个提供功能的服务都拥有自己独立的鉴权和授权机制。
-
每个提供功能的服务都拥有自己独立的数据库,来保存敏感信息。
-
每次用户请求都需要携带用户的credential来完成操作
小结下使用这种方案的好处:
-
微服务的应用可以实现100%无状态化
-
基于Basic Auth开发简单
同时,小结下使用这种方案需要注意的地方:
-
由于每个服务都有自己存储credential的机制,需要事先为每个服务设计好如何存储和查找用户的Credential
-
由于每次用户请求都会携带用户的Credential,需要事先设计好如何管理鉴权机制
2. 微服务常用访问安全设计方案——Basic Auth + Central Auth DB
第二种,如上示意图所示,使用Basic Auth协议,与第一种方案相比,每个服务共用有同一个Auth DB。
第二种方案的特点和第一种很相似:
-
每个提供功能的服务都拥有自己独立的鉴权和授权机制。
-
每个提供功能的服务共用同一个DB,来保存Credential等敏感信息。
-
每次用户请求都需要携带用户的credential来完成操作。
小结下使用第二种方案的好处:
除了拥有第一种方案相似的好处外,由于共用了同一个持久化仓库来管理用户信息,简化了原来独立管理的机制。
同时,小结下使用这种方案需要注意的地方:
-
中心化Auth DB会被每次用户请求来访问连接,可能引发AuthDB性能瓶颈。
-
需要在每个服务中实现对共有Auth DB查找用户信息的逻辑。
3. 微服务常用访问安全设计方案——API Tokens
第三种,如上示意图所示,使用Token Based协议来对用户请求进行操作鉴权。
简单介绍下最基本的Token Based的交互方式:
-
用户使用包含用户名和密码的credential从客户端发起资源请求。
-
后端接受请求,通过授权中心,生产有效token字符串,返回给客户端。
-
客户端获得token后,再次发出资源请求。
-
后端接受带token的请求,通过授权中心,获取相关资源,返回给客户端。
业界常用的OAuth就是基于Token Based这套逻辑,实现的互联网级的鉴权机制。
第三种方案的特点明显:
-
使用token来进行鉴权,替换用户本身的用户名和密码,提高了交互安全性。
-
每次用户请求需要携带有效token,与Auth服务进行交互验证。
小结下使用第三种方案的好处:
由于使用了token来鉴权,业务服务不会看到用户的敏感信息。
同时,小结下使用这种方案需要注意的地方:
Auth服务可能需要处理大量的生产token的操作。
4. 微服务常用访问安全设计方案——SAML
第四种,如上示意图所示,使用SAML协议来对用户请求进行操作鉴权。它是一个基于XML的标准,用于在不同的安全域(security domain)之间交换认证和授权数据。
在SAML标准定义了身份提供者(identity provider)和服务提供者(service provider),这两者构成了前面所说的不同的安全域。
以上图Google提供的Apps SSO的机制,简单介绍下SAML鉴权的交互方式:
-
用户请求访问自建的google application
-
当前application 生成一个 SAML 身份验证请求。SAML 请求将进行编码并嵌入到SSO 服务的网址中。
-
当前application将重定向发送到用户的浏览器。重定向网址包含应向SSO 服务提交的编码 SAML 身份验证请求。
-
SSO(统一认证中心或叫Identity Provider)解码 SAML 请求,并提取当前application的ACS(声明客户服务)网址以及用户的目标网址(RelayState 参数)。然后,统一认证中心对用户进行身份验证。
-
统一认证中心生成一个 SAML 响应,其中包含经过验证的用户的用户名。按照 SAML 2.0 规范,此响应将使用统一认证中心的 DSA/RSA 公钥和私钥进行数字签名。
-
统一认证中心对 SAML 响应和 RelayState 参数进行编码,并将该信息返回到用户的浏览器。统一认证中心提供了一种机制,以便浏览器可以将该信息转发到当前application ACS。
-
当前application使用统一认证中心的公钥验证 SAML 响应。如果成功验证该响应,ACS 则会将用户重定向到目标网址。
-
用户将重定向到目标网址并登录到当前application。
目前SAML在业界也有相当的使用度,包括IBM Weblogic等产品。
第四种方案的特点有:
-
由Identity Provider提供可信的签名声明
-
服务的访问安全由可信的Identity Provider提供
小结下使用第四种方案的好处:标准的可信访问模型
同时,小结下使用这种方案需要注意的地方:
-
基于XML协议,传输相对复杂
-
对非浏览器客户端适配不方便
四、Spring Cloud Security解决方案
Spring Cloud Security特点有:
-
基于OAuth2 和 OpenID协议的可配置的SSO登录机制
-
基于tokens保障资源访问安全
-
引入UAA鉴权服务,UAA是一个Web服务,用于管理账户、Oauth2客户端和用户用于鉴权的问题令牌(Issue Token)。UAA实现了Oauth 2授权框架和基于JWT(JSON web tokens)的问题令牌。
下面简单介绍下UAA,事实上,它是由CloudFoundry发起的,也是CloudFoundry平台的身份管理服务(https://docs.cloudfoundry.org/concepts/architecture/uaa.html)。
主要功能是基于OAuth2,当用户访问客户端应用时,生成并发放token给目标客户端。
UAA认证服务包含如下几个方面的内容:
-
认证对象。如用户、客户端以及目标资源服务器
-
认证类型。主要有授权码模式、密码模式以及客户端模式
-
认证范围,即认证权限,并作为一个命名的参数附加到AccessToken上。
-
接下来,结合实例,一起来看下UAA在Spring Cloud中的实践。
如图所示,这是一个简单的基于Spring Cloud微服务架构的例子,它的主要组件有:
-
Eureka组件提供服务发现功能
-
独立的Config组件提供类似配置中心的服务,持久化层可以是文件系统,也可是git repository
-
Auth组件提供基于UAA的鉴权服务
-
Account组件保存用户的业务信息
-
其他组件不一一介绍了
这里主要讲Auth组件和Account组件是如何基于UAA服务进行认证和授权。
图一为Auth组件业务代码中定义了不同客户端的认证类型和认证范围,其中
-
浏览器端的认证类型是password,认证范围是ui
2 -
account组件端的认证类型是client_credentials,认证范围是server
-
图二为config组件(配置中心)定义的请求路由的规则,其中:
-
使用/uaa/**来转发基于uaa的认证请求至auth组件
-
使用/accouts/**来转发请求至account组件,并标记serviceId为account-service,与图一中的withClient对应。
图一为浏览器打开应用入口后,输入用户名和密码后,发出的认证请求:
-
认证url为/uaa/oauth/token,这是uaa模式下标准的请求获取token的url
-
表单中包含了字段scope(认证范围)和字段password(认证类型)
图二为图一发出认证请求的返回结果:
Access_token为有效认证token,将来被其他请求使用
图三为发出获取当前用户的信息的请求:
在请求里的Authorization的值为图二中获得的access_token
图一为Account组件在Config组件(配置中心)定义的OAuth2协议下获取token的方式,这里定义了:
-
clientID和clientSecret
-
accessTokenUrl,这里指定了auth组件的uaa获取token的url
-
grant-type,即认证类型,这里指定为client_credentials
-
scope,这里指定了server,说明是这个认证请求只适用在各微服务之间的访问。
图二为Accout组件业务代码中定义了需要使用Auth组件进行事先鉴权的方法:
-
使用@PreAuthorize
-
annotation中可以指定认证范围的具体条件,这里是限定了server或者是demo账户,才有权限发起认证。
最后小结下Spring Cloud Security的特点:
-
基于UAA,使用OAuth2协议。不会暴露用户的敏感信息
-
基于认证类型和认证范围,实现细粒度的鉴权机制
-
非浏览器客户端下良好的操作性