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代码给服务消费方。

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

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对象。