API网关(4) --认证授权

1.需求背景

随着各业务系统逐步完成服务化改造并接入注册中心,随即而来的服务注册与调用的安全问题有待解决
首先,原生的Eureka作为服务注册中心对服务注册没有权限控制,服务可以任意注册,而且通过接口可以获取所有已注册的服务信息,存在很大的安全隐患。
其次,外部请求以及跨Space的服务请求存在恶意攻击的风险,需要防范和识别这两类请求,保障服务安全调用

2.设计目标

  • 对各网络区域的业务系统进行逻辑划分,每个业务系统为一个Space
  • 不同Space之间进行网络策略隔离,需通过认证服务器(Authorization server)拿到Token以及API网关授权后,才能访问其他Space资源;只有在特殊情况下才允许将Space间网络打通并直接调用
  • 每个Space需有独立的网关服务,为确保高可用,网关以集群方式提供,并按照部署环境的不同(容器云、虚拟机)确定是否部署nginx
  • 每一个Space的所有服务共享注册中心,服务通过认证后才能访问注册中心
  • 服务调用安全方案落地需要各业务系统配合,相关接入逻辑拟与已发布的eureka starter进行整合,降低推广和接入成本

3.技术选型

Spring Cloud Zuul + Spring Security + JWT + activiti工作流 + mysql

4.解决方案

4.1 系统物理部署图(虚拟机环境部署方案,非容器)

服务安全调用逻辑架构.png

如上图所示,各业务系统前端或授权管理系统前端静态页面都部署于web区;API网关使用Spring Cloud Zuul实现,为确保Zuul高可用,API网关采用集群形式部署,并由nginx做负载均衡,需要注册在各个space的注册中心。

4.1.1 服务调用类型

根据设计目标,服务间调用主要分为以下三种类型:

  1. 跨Space之间的调用
  2. 同一Space内的服务调用

4.1.2 技术方案

对于同一个Space内的两个服务之间的调用,不需要经过nginx和网关,在注册中心注册后通过ribbon直接调用。

对于不在同一个Space的两个服务,服务消费者得请求都要经过nginx分发到目标网关,授权成功后再向服务提供者发起请求。

4.2 服务认证、授权全流程

服务安全调用逻辑图.png

完整的服务调用认证授权流程如上图所示,对流程分解如下:

  1. 授权认证准备
    当服务需要对外提供接口时,需要在认证授权管理系统中登记,说明要对外开放的接口信息,当有服务需要调用该接口时,需要发起申请审批流程
  2. 授权认证流程
    同一个Space内的服务是互信的,所以Space N内的Service C可以直接请求Service A。
    但是如果Service A需要跨Space请求Service B,则需要完成认证授权流程。
  3. 服务消费方
    服务消费方Service A接入安全组件(Jar包形式),安全组件使用RestTemplate拦截器是调用请求带上http header(包括clientName,clientSecret)去请求 OAuth2 Server 获取 JWT,(注意:安全组件会定时采集JWT并存入内存中,以保证不用每次都通过网络去请求JWT)然后生成带有JWT头信息的RestTemplate请求。
  4. 认证服务器
    OAuth2 Server 从接受请求到返回JWT,具体步骤如下:
    OAuth2 Server 去数据库查询 client 表,验证 clientName、clientSecret 是否正确,如正确跳转至下一步。
    OAuth2 Server 根据 Service A 传过来的 clientName 查 client 表获取对应的 Space 和 Space 的私钥
    OAuth2 Server 将 clientName 与 clientId封装至 JWT ,并使用上一步获取的私钥对 JWT 进行签名
  5. 服务消费方
    服务消费方 Service A 带上获取到的 JWT(在 http header 中),通过 Space M 的 网关将请求分发,去访问 Service B ,但是在网关分发请求前,必须通过授权
  6. API网关
    服务消费方 Service A 的请求分发到 API网关 时,网关的授权流程如下:
网关授权流程图.png

如上图所示,当 JWT 非空时,利用 Base64 反编码解析出 clientId,并根据 clientId 查找本地缓存中对应的公钥,若本地缓存不存在则从 OAuth2 Server 请求公钥并写入本地缓存;利用缓存的公钥和 JWT 进行验签,通过则跳转至下一步;根据clientId查找本地缓存中对应的URI,与当前请求的URI比对,判断服务消费方是否有权访问此URI;如果此用户具有访问此URI的权限,网关放行,如无权限则直接拒绝,返回401代码给服务消费方。

  1. API网关通过 Ribbon,代理请求到服务提供方,即 Service B
  2. 服务提供方处理完请求后,通过网关将调用结果返回到服务消费方

5. 总结

如图,位于 Space N 的 Service A 需要远程调用位于 Space M 的 Service B

具体的认证授权流程为:

5.1 安全接入组件(获取JWT的过程不会侵入业务代码,通过restTemplate拦截器实现)

1. Service A 带上http header(包括clientId,clientSecret)去访问OAuth Server,OAuth Server从接收请求到返回 JWT 需要如下步骤:

 1.1 OAuth Server 去数据库查询 client 表,验证clientName、clientSecret是否正确,如正确跳转至步骤1.2

 1.2 OAuth Server 查询表 client,获取到 client 表的主键 clientId

 1.3 OAuth Server 根据 Service A 传过来的 clientName 查 client 表获取该client的私钥

 1.4 OAuth Server 将 client 表的 id 字段封装至 JWT,并使用步骤1.3中获取的私钥对 JWT 进行签名

Service A 获取 JWT 后存储到内存,只有在 JWT 快要超时时,才会再次向 OAuth Server 发送获取 JWT 请求,在超时时间内,Service A 直接使用内存中的 JWT 进行远程调用

2. Service A 带上 JWT 去访问 Space M 的 API网关,首先会通过 Space M 的 nginx 对请求分发

3. Service A 的调用分发到 API 网关时,网关的具体执行步骤如下:

5.2 网关

 3.1 网关初次启动时,会调用批量查询公钥、批量查询权限列表接口,并缓存到本地Map(pubKeyCacheData、uriCacheData)
 3.2 当接收到一个请求时,取出 header 里的 access_token 首先对其进行 Base64 反编码,获取到 clientId
 3.3 拿到 clientId 后,用 3.1 获取的 clientId 的 对应公钥对 JWT 验签,验签通过后与内存中的 uriCacheData 进行对比,判断调用者是否有权访问此 URI
注:为了降低数据库的压力,API网关采用失败再查询方式,通过 OAuth Server 提供的接口更新本地 client-List<uri> 对应关系,从而不用每来一次请求就查数据库
 3.4 如用户具有访问此 URI 的权限,网关放行,如再次查询后无权限则直接拒绝,返回 401 代码给 Servce A

4. API网关通过从 Eureka 获取的路由信息,转发请求到 Service B

5. 服务B处理完成后,通过网关将调用结果返回到 Service A

6 OAuth2

API网关认证授权是采用的 OAuth2 的客户端模式

OAuth是一个关于授权(authorization)的开放网络标准,目前的版本是2.0版。只要授权方和被授权方遵守这个协议去写代码提供服务,那双方就是实现了OAuth模式。

名词定义:
(1) Third-party application:第三方应用程序,本文中又称"客户端"(client),即上一节例子中的"云冲印"。
(2)HTTP service:HTTP服务提供商,本文中简称"服务提供商",即上一节例子中的Google。
(3)Resource Owner:资源所有者,本文中又称"用户"(user)。
(4)User Agent:用户代理,本文中就是指浏览器。
(5)Authorization server:认证服务器,即服务提供商专门用来处理认证的服务器。
(6)Resource server:资源服务器,即服务提供商存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器。

OAuth2一共有四种模式:授权码模式、简化模式、密码模式、客户端模式

这里只介绍用的比较多的授权码模式和客户端模式

6.1 授权码模式

image.png

它的步骤如下:

(A)用户访问客户端,后者将前者导向认证服务器。

(B)用户选择是否给予客户端授权。

(C)假设用户给予授权,认证服务器将用户导向客户端事先指定的"重定向URI"(redirection URI),同时附上一个授权码。

(D)客户端收到授权码,附上早先的"重定向URI",向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。

(E)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。

6.2 客户端模式(Client Credentials Grant)

指客户端以自己的名义,而不是以用户的名义,向"服务提供商"进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求"服务提供商"提供服务,其实不存在授权问题。

image.png

它的步骤如下:

(A)客户端向认证服务器进行身份认证,并要求一个访问令牌。

(B)认证服务器确认无误后,向客户端提供访问令牌。

7 JWT

API网关认证鉴权中的 Token 是采用 JWT 实现

7.1 JWT 原理

JSON Web Token(JWT)是目前最流行的跨域身份验证解决方案。

传统的身份验证

1.用户向服务器发送用户名和密码。

2.验证服务器后,相关数据(如用户角色,登录时间等)将保存在当前会话中。

3.服务器向用户返回session_id,session信息都会写入到用户的Cookie。

4.用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。

5.服务器收到session_id并对比之前保存的数据,确认用户的身份。

这种模式最大的问题是,没有分布式架构,无法支持横向扩展。如果使用一个服务器,该模式完全没有问题。但是,如果它是服务器群集或面向服务的跨域体系结构的话,则需要一个统一的session数据库库来保存会话数据实现共享,如果保存session的缓冲数据库挂掉,整个认证体系都会挂掉。

JWT 的身份验证

JWT的原则是在服务器身份验证之后,将生成一个JSON对象并将其发送回用户

之后,当用户与服务器通信时,客户在请求中带上JSON对象。服务器仅依赖于这个JSON对象来标识用户。为了防止用户篡改数据,服务器将在生成对象时添加签名。

服务器不保存任何会话数据,即服务器变为无状态,使其更容易扩展。

7.2 JWT的数据结构

JWT的三个部分如下。JWT头、有效载荷和签名

image.png

头部保存了签名算法、令牌类型(JWT),最后,使用Base64 URL算法将上述JSON对象转换为字符串保存。

有效载荷部分,是JWT的主体内容部分,也是一个JSON对象,包含需要传递的数据,JSON对象也使用Base64 URL算法转换为字符串保存。默认情况下是未加密的,API网关保存的clientId就存在于这一部分中

签名哈希部分是对上面两部分数据签名,通过指定的算法生成哈希,以确保数据不会被篡改。使用标头中指定的签名算法(默认情况下为HMAC SHA256)通过私钥签名。

在计算出签名哈希后,JWT头,有效载荷和签名哈希的三个部分组合成一个字符串,每个部分用"."分隔,就构成整个JWT对象。

推荐阅读更多精彩内容