技术分享｜明源云天际集成开放平台接口中心基于IdentityServer4的鉴权机制

Posted 2021-09-07 dotNET跨平台

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了技术分享｜明源云天际集成开放平台接口中心基于IdentityServer4的鉴权机制相关的知识，希望对你有一定的参考价值。

源宝导读：企业数字化生态建设中为解决集成多样性和资源统一管理的痛点引入企业级网关，网关作为资源访问的大门，身份认证鉴权是其业务的重中之重，本文将介绍企业级网关-天际集成开放平台是如何通过IdentityServer4来做到身份认证和鉴权业务的。

天际集成开放平台业务简述

明源云天际集成开放平台（以下简称“集成平台”）是明源打造的一套高可用、高并发、高性能的企业网关，是解决企业数字化生态打造中的资源连接多样性和资源生态管理困难等痛点。企业周边生态复杂多样，各种业务系统层出不穷，给资源的统一管理和连接带来了巨大的挑战。

集成平台采用分布式系统架构，来应对挑战。由接口中心、连接中心、事件中心、门户、监控中心、服务流ETL和方案中心等组成（如图1所示），其中接口中心是系统的统一入口，负责资源的管理，所有的请求都由接口中心来转发处理，其他中心负责其相关核心业务。

结合这次分享的主题，我将对接口中心基于IdentityServer4的鉴权机制进行详细的分享，其他业务将在后续的文章中体现，敬请期待。

（图1）

IdentityServer4 徽标

IdentityServer4 介绍

IdentityServer4框架，是为ASP.NET CORE量身定制的实现了 OpenID Connect 和 OAuth 2.0 的认证授权中间件。

IdentityServer4 官方支持时间和商业许可

IdentityServer4 官方错误修复和安全更新的维护时间直到2022年11月。
IdentityServer4 使用 Apache2 许可的许可证，该许可证允许在其之上构建商业产品。

一、概述

由于接口中心的特殊定位，使其还兼顾着网关相关的安全策略和统一业务处理。在接口中心的设计上选择了.NET生态中一套非常成熟的网关设计方案 Ocelot + Consul + IdentityServer4，集成平台基于自身业务的需要在Ocelot的运行管道中进行了相关中间件的扩展，如图2所示。其中Api鉴权中心中间件的设计便是结合了IdentityServer4相关技术来进行打造的。

集成平台为客户连接一切可连接的资源，用户在将资源进行上线管理时，担忧的是安全问题、访问权限问题。针对这两点，首先我们提供了统一的网关入口，建议用户将资源放在内网，隔绝外网直接访问资源，然后针对需要获取客户资源的第三方用户，提供网关的Token颁发地址，目前我们支持三种获取Token的接口，分别为 JWT(Json web token)、OAuth2.0 Client、OAuth2.0 Sign。在平台上客户会给第三方添加应用，为应用分配AppKey和AppSecret，第三方用户拿到AppKey和AppSecret来请求Token获取令牌。在给第三方应用颁发Token时，会将授权资源信息保存起来，供身份认证通过后，进行资源授权校验，综上所述，如图3所示。

为了更好让大家理解 IdentityServer4 下面将对它进行详细的说明，并结合集成平台的身份认证授权案列来进行阐述。

（图2）

（图3）

二、相关术语解释

① User：用户

② Client：客户端

③ Resources：Identity Data（身份数据）、Apis

④ Identity Server：认证授权服务器

⑤ Token：Access Token（访问令牌）和 Identity Token（身份令牌）

⑥ JWT：Json web token 详情请看JWT官网

三、OAuth2.0和OpenId Connect协议理解

由于OAuth2.0和OpenId Connect协议在网络上，有很多技术文章进行解说了，大家可以自行百度了解，这里简单说下这两种协议的定义和相关点说明。
（一）OAuth 2.0用于授权

定义：OAuth（开放授权）是一个开放标准，目前的版本是2.0。允许用户授权第三方移动应用访问他们存储在其他服务商上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。OAuth允许用户提供一个令牌而不是用户名和密码来访问他们存放在特定服务商上的数据。每一个令牌授权一个特定的网站内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth可以允许用户授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

1、OAuth2.0 定义了四种授权模式：

（1）Implicit：简化模式；直接通过浏览器的链接跳转申请令牌。

（A）客户端携带client_id、redirect_uri，中间通过代理者访问授权服务器，如果已经登录过会直接返回redirect_uri，没有登录过就跳转到登录页面

（B）授权服务器对客户端进行身份验证(通过用户代理，让用户输入用户名和密码）

（C）授权通过，会重定向到redirect_uri并携带授权码token作为uri参数

（D）客户端携带授权码访问资源服务器

（E）验证token通过，返回资源

(图4)

（2）Client Credentials：客户端凭证模式，是最简单的授权模式，因为授权的流程仅发生在Client与Identity Server之间。该模式的适用场景为服务器与服务器之间的通信。比如对于一个房地产ERP系统，将房产库存和销售分拆为两个服务分别部署。销售系统需要访问库存系统进行房间的跟踪，库存系统需要访问销售系统的销售单号信息进行房间信息的定时刷新。而这两个系统之间服务的授权就可以通过这种模式来实现。

（图5）

（3）Resource Owner Password Credentials：密码模式相较于客户端凭证模式，多了一个参与者，就是User(资源所有者)。通过User的用户名和密码向Identity Server申请访问令牌。这种模式下要求客户端不得储存密码。但我们并不能确保客户端是否储存了密码，所以该模式仅适用于受信任的客户端。否则会发生密码泄露的危险。该模式不推荐使用。

（图6）

（4）Authorization Code：授权码模式是一种混合模式，是目前功能最完整、流程最严密的授权模式。它主要分为两大步骤：认证和授权。其流程为：

(A)用户访问客户端，客户端将用户导向Identity Server。

(B)用户填写凭证信息向客户端授权，认证服务器根据客户端指定的重定向URI，并返回一个【Authorization Code】给客户端。

(C)客户端根据【Authorization Code】向Identity Server申请【Access Token】

（图7）

（二）OpenId Connect用于授权身份认证

定义：OpenID Connect 1.0 是基于OAuth 2.0协议之上的简单身份层，它允许客户端根据授权服务器的认证结果最终确认终端用户的身份，以及获取基本的用户信息；它支持包括Web、移动、javascript在内的所有客户端类型去请求和接收终端用户信息和身份认证会话信息；它是可扩展的协议，允许你使用某些可选功能，如身份数据加密、OpenID提供商发现、会话管理等。

（三）JWT 理解

我们使用的Token格式为JWT(Json web token)。其特殊的三段式结构结合签名的方式，使Token更加的安全和可读（头部和有效载荷都为Base64URl加码）。而且这种类型的Token的特点非常适合Http无状态的方式，让分布式的系统通过Jwt来作为身份和认证的统一令牌，让服务器无状态，无关联影响。

四、集成平台身份认证授权案例

在前言中提到我们在Ocelot网关的管道中扩展很多自己的业务管道，其中就包含了平台的身份认证授权中间件，其实在Ocelot中是有内置的中间件的，为什么我们要自己实现一套中间呢？首先我们作为企业网关，除了要兼容标准的各种验证方式，以及兼容替换其他第三方网关的认证方式，还要结合我们明源自己的软件产品生态，比如兼容云客、云空间的身份认证模式等等，由于Ocelot自身没办法满足我们特殊定制的需要，所以自己实现了一套基于Ocelot管道的身份认证。

IdentityService4作为独立的认证服务，必须要知道哪些资源需要配置和保护，也必须知道哪些客户端被允许访问资源，我们在概述中提到了集成平台的身份认证验证过程图3所示，首先在集成平台的云控制台添加资源，然后根据不同的访问系统创建应用信息并颁发AppKey和AppSecret。资源和应用的对应关系我们实例化在数据库中，并把资源和应用的绑定关系同步在Consul KV中，在调用的时候系统首先获取到Token然后携带Token并来到集成平台网关，通过目前Api请求Token和认证方式，进行Token身份认证，认证通过后将通过Api的唯一标识从Consul KV中获取对应关系，进行授权认证。那数据库中持久化的关系和Consul KV 中的数据怎么保证一致性呢？首先在集成平台云端控制台进行授权配置的时候采用事务的方式来保证数据库和Consul中的数据一致性，并采用Consul 的KV变更监控来防止直接修改信息导致的数据不一致性。下面是集成平台网关相关配置的几个点。

（1）首先配置允许授权颁发Token令牌接口匿名访问，集成平台目前实现了三种验证方式并提供了获取令牌的接口。