聊聊统一身份认证服务

导读

当企业的应用系统逐渐增多后，每一个系统单独管理各自的用户数据容易造成信息孤岛，分散的用户管理模式阻碍了企业应用向平台化演进。当企业的业务发展到必定规模，构建统一的标准化帐户管理体系将是必不可少的，由于它是企业云平台的重要基础设施，可以为平台带来统一的账号管理、身份认证、用户受权等基础能力，为企业带来诸如跨系统单点登陆、第三方受权登陆等基础能力，为构建开放平台和业务生态提供了必要条件。

背景

公司原有的各个业务系统都是经过域帐户来打通的，随着公司平台化、开放战略的推动，公司对外提供的服务必须具有对外集成与被集成的能力，在这种需求下，单纯的内部帐户打通已显然不能知足需求，提供统一的帐户管理、身份认证与受权势在必行。
以咱们的DevOps平台研发协同平台为例，平台要面向ISV合做伙伴开放, 首先面临的就是帐户问题，不仅仅是研发协同平台自身要向ISV合做提供服务，围绕研发协同平台的其余服务（例如Jira, Confluence, Jenkins, Sonar）也要面向ISV合做伙伴提供服务，这就要求面向ISV合做伙伴必须提供统一的帐户体系。

需求

统一身份管理
统一身份管理是整个平台账号和权限管控的基础，平台下全部系统的帐户管理、身份认证、资源受权等行为都经由系通通一处理，提供账号密码管理、基本资料管理、资源管理、受权管理、客户端管理等功能。统一身份管理基于统一身份治理的概念，可划分为帐户体系、基础信息、资源受权三大模块。
其中帐户体系将帐户分为组织实体账号和我的实体帐户两大类，我的实体从属于组织实体，也能够不从属任何组织实体，且我的实体可同时从属于多个组织实体；基础信息模块用于描述组织实体和我的实体的基本信息，如组织实体名称、地址、法人，我的实体姓名、电话号码、性别等基础信息；资源受权模块将须要对外提供服务的业务服务资源进行统一管理和受权。

组织实体
在统一认证身份服务中，组织机构应当是一种实体，与之对应的另外一种实体是我的实体（业务上是实体概念，和帐户是有区别的）。所以要设计一种用于组织实体登入系统的方法，这里有两种可选方案：一是增长组织实体帐户，组织实体自身拥有帐户，可直接进行认证登陆；二是将从属于组织实体的我的帐户做为组织实体的登入凭证。不管何种方法，在认证和受权时，都由统一身份认证服务提供统一标准的帐户凭证，所以，组织实体的认证受权与我的实体的认证受权并没有二致

单点登陆（SSO）
企业平台涉及众多子系统，为简化各子系统的用户管理，提高用户体验，所以实现 SSO 是统一身份认证的重要目标：一次登陆，所有访问。对于企业内部应用来讲，SSO 是必须的选项，例如企业 OA、HR、CRM 等内部系统；对于外部应用来讲，SSO 是可选项，具体哪一个应用应当加入 SSO 系统，由该业务系统决定。不管何种应用服务是否采用 SSO，统一身份认证服务在技术上应当具有 SSO 的能力。

受权登陆
随着平台业务的逐渐增加，依托于平台的，和平台依托的厂商和客户等资源将极大的丰富平台，所以必须构筑开放的生态系统，以支撑业务的进一步发展。必须开放平台级的受权登陆功能，以容许第三方应用接入。

资源受权
企业业务服务除了要集成第三方服务来提高服务能力，也须要对外提供服务，提供被集成的能力，这样才能和第三方一块儿构建生态合做伙伴关系，实现双赢。所以，统一身份认证服务除了要提供认证，还须要提供服务资源受权的能力，以受权第三方集成企业提供的业务服务，将企业的业务服务开放给第三方，实现共同发展。

技术方案

IdentityServer4是基于ASP.NET Core的OpenID Connect和OAuth 2.0框架。它提供了如下丰富的功能：
身份验证即服务
适用于全部应用程序（Web，本机，移动设备，服务）的集中登陆逻辑和工做流程。IdentityServer是OpenID Connect 的官方认证明现。
单点登陆/注销
在多种应用程序类型上单点登陆（和退出）。
API访问控制
为各类类型的客户端发出API访问令牌，例如服务器到服务器，Web应用程序，SPA和本机/移动应用程序。
联合网关
支持Azure Active Directory，Google，Facebook等外部身份提供商。这能够保护您的应用程序免受如何链接到这些外部提供商的详细信息的影响。
可定制
最重要的部分 - IdentityServer的许多方面均可以根据您的需求进行定制。因为IdentityServer是一个框架而不是盒装产品或SaaS，所以您能够编写代码以使系统适应您的方案。
成熟的开源
IdentityServer使用容许的Apache 2许可证，容许在其上构建商业产品。它也是.NET Foundation的一部分，它提供治理和法律支持。

OAuth2.0 && OpenId Connect

IdentityServer4是基于ASP.NET Core的OpenID Connect和OAuth 2.0框架，咱们先来了解OpenId Connect和OAuth 2.0的基本概念

OpenId
OpenID 是一个以用户为中心的数字身份识别框架，它具备开放、分散性。OpenID 的建立基于这样一个概念：咱们能够经过 URI （又叫 URL 或网站地址）来认证一个网站的惟一身份，同理，咱们也能够经过这种方式来做为用户的身份认证。
简而言之：OpenId用于身份认证（Authentication）
OAuth 2.0
OAuth（开放受权）是一个开放标准，目前的版本是2.0。容许用户受权第三方移动应用访问他们存储在其余服务商上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
OAuth容许用户提供一个令牌而不是用户名和密码来访问他们存放在特定服务商上的数据。每个令牌受权一个特定的网站内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth能够容许用户受权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非全部内容。
OAuth是OpenID的一个补充，可是彻底不一样的服务。
简而言之：OAuth2.0 用于受权（Authorization）
OpenId Connect
OpenID Connect 1.0 是基于OAuth 2.0协议之上的简单身份层，它容许客户端根据受权服务器的认证结果最终确认终端用户的身份，以及获取基本的用户信息；它支持包括Web、移动、JavaScript在内的全部客户端类型去请求和接收终端用户信息和身份认证会话信息；它是可扩展的协议，容许你使用某些可选功能，如身份数据加密、OpenID提供商发现、会话管理等。
简而言之：OpenId Connect = OIDC = Authentication + Authorization + OAuth2.0

术语

了解完OpenId Connect和OAuth2.0的基本概念，咱们再来梳理下涉及到的相关术语：

Identity Server
认证受权服务器，是OpenID Connect提供程序， 它实现了OpenID Connect和OAuth 2.0协议。主要包括如下功能：

• 保护资源
• 使用本地账户存储或外部身份提供程序对用户进行身份验证
• 提供会话管理和单点登陆
• 管理和验证客户端
• 向客户发放身份和访问令牌
• 验证令牌

用户（Users
用户是使用注册客户端访问资源的人

客户端（Client）
客户端是从IdentityServer请求令牌的应用 - 用于验证用户（请求身份令牌）或访问资源（请求访问令牌）。客户端必须首先向IdentityServer注册，而后才能请求令牌。常见的客户端包括Web应用程序，本机移动或桌面应用程序，SPA，服务器进程等。

资源（Resources）
使用IdentityServer保护的资源 - 用户的身份数据或服务资源(API)。每一个资源都有一个惟一的名称 - 客户端使用此名称来指定他们但愿访问哪些资源。身份数据 - 关于用户的身份信息（也称为声明），例如姓名或电子邮件地址等。服务资源(API) - 表示客户端要调用的服务 - 一般为Web API，但不必定。

令牌(Token)
令牌有身份令牌（Identity Token）和访问令牌（Access Token）。身份令牌表示身份验证的结果。它至少包含用户标识以及有关用户如何以及什么时候进行身份验证的信息，还能够包含其余身份数据。访问令牌容许访问API资源,客户端请求访问令牌并将其转发给API。访问令牌包含有关客户端和用户（若是存在）的信息,API使用该信息来受权访问其资源。

JWT认证

HTTP身份验证流程
HTTP提供了一套标准的身份验证框架：服务器能够用来针对客户端的请求发送质询(challenge)，客户端根据质询提供身份验证凭证。质询与应答的工做流程以下：服务器端向客户端返回401（Unauthorized，未受权）状态码，并在WWW-Authenticate头中添加如何进行验证的信息，其中至少包含有一种质询方式。而后客户端能够在请求中添加Authorization头进行验证，其Value为身份验证的凭证信息。

Bearer认证（也叫作令牌认证）是一种HTTP认证方案，其中包含的安全令牌的叫作Bearer Token。所以Bearer认证的核心是Token。那如何确保Token的安全是重中之重。一种方式是使用Https，另外一种方式就是对Token进行加密签名。而JWT就是一种比较流行的Token编码方式。

JWT（Json Web Token)
Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登陆（SSO）场景。JWT的声明通常被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也能够增长一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
JWT有三部分组成：

<header>.<payload>.<signature>

Header - 由alg和typ组成，alg是algorithm的缩写，typ是type的缩写，指定token的类型。该部分使用Base64Url编码。

Payload - 主要用来存储信息，包含各类声明，一样该部分也由BaseURL编码。

Signature - 签名，使用服务器端的密钥进行签名。以确保Token未被篡改。

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

受权模式

IdentityServer4提供了如下几种常见的受权模式：Client Credentials(客户端凭证模式)， Resource Owner Password Credentials(密码模式)， Implicit(简化模式)，Authorization Code, Device Flow(设备模式)

Client Credentials （客户端凭证模式）

POST https://api.oauth2server.com/token grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET

客户端凭证模式是最简单的受权模式，由于受权的流程仅发生在Client与Identity Server之间。该模式的适用场景为服务器与服务器之间的通讯。好比对于一个电子商务网站，将订单和物流系统分拆为两个服务分别部署。订单系统须要访问物流系统进行物流信息的跟踪，物流系统须要访问订单系统的快递单号信息进行物流信息的定时刷新。而这两个系统之间服务的受权就能够经过这种模式来实现。

Resource Owner Password Credentials (密码模式)

POST https://api.oauth2server.com/token grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID

Resource Owner其实就是User，因此能够直译为用户名密码模式。密码模式相较于客户端凭证模式，多了一个参与者，就是User。经过User的用户名和密码向Identity Server申请访问令牌。这种模式下要求客户端不得储存密码。但咱们并不能确保客户端是否储存了密码，因此该模式仅适用于受信任的客户端。不然会发生密码泄露的危险。该模式不推荐使用。

Implicit (简化模式)

Implicit Flow 又称为简化流程，由于没有任何后台服务参与使用 Authorization Grant 换取 Access Token 的流程，整个过程由 Browser 直接与 Authorization Server 通讯。

Authorization Code

受权码模式是一种混合模式，是目前功能最完整、流程最严密的受权模式。它主要分为两大步骤：认证和受权。简称为 Code Flow，也是 OAuth 推崇的方案，该 Flow 同时采用了 Front Channel 和 Back Channel。它常见于 Web App 的场景。Client 应用程序经过 Front Channel 向 Authorization Server 申请 Authorization Code，再经过 Back Channel 用 Authorization Code 换取 Access Token。它假定 Resource Owner 和 Client 应用程序运行在不一样的设备上，Access Token 始终不会传输到「用户代理应用程序」

Device Flow

用于相似 TV 等硬件设备，或仅仅运行一个 Cli 的程序，直接与 Authorization Server 通讯取得一个 code，再用 code 换取 Access Token 的流程。

身份认证服务实践

在ASP.NET Core Wen API应用程序中配置和启用Identity server中间件

• services.AddIdentityServer() - 配置identity server中间件
• AddInMemoryIdentityResources - 配置身份资源
• AddInMemoryApiResources - 配置API资源
• AddInMemoryClients - 配置客户端
• AddTestUsers - 配置用户

SonarQube集成身份认证服务受权登陆

1. 使用管理员身份登陆SonarQube, 进入配置->通用设置->权限 设置OpenId Connect
   

2. 设置完成，注销帐户，在登陆页面选择经过OpenId Connect登陆, 便可使用身份认证服务受权登陆SonarQube系统
   

写在最后

在互联网这个开放体系中，任务企业均可以集成第三方的服务来提高本身的服务能力，同时也能够将本身的服务能力开放给第三方提供被集成的能力，从而构建一个开放、双赢的生态体系。要开放、也要连接，而这绕不开的一个点就是认证受权问题。统一身份认证服务应运而生，各企业再也不拘泥于内部的身份统一，在企业服务与企业服务之间创建安全可靠的连接，可以增强信息的流通、服务能力的提高，促进企业生态的发展。