聊聊統一身份認證服務

導讀

當企業的應用系統逐漸增多後，每一個系統單獨管理各自的用戶數據容易造成信息孤島，分散的用戶管理模式阻礙了企業應用向平臺化演進。當企業的業務發展到必定規模，構建統一的標準化帳戶管理體系將是必不可少的，由於它是企業雲平臺的重要基礎設施，可以爲平臺帶來統一的賬號管理、身份認證、用戶受權等基礎能力，爲企業帶來諸如跨系統單點登陸、第三方受權登陸等基礎能力，爲構建開放平臺和業務生態提供了必要條件。

背景

公司原有的各個業務系統都是經過域帳戶來打通的，隨着公司平臺化、開放戰略的推動，公司對外提供的服務必須具有對外集成與被集成的能力，在這種需求下，單純的內部帳戶打通已顯然不能知足需求，提供統一的帳戶管理、身份認證與受權勢在必行。
以咱們的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系統
   

寫在最後

在互聯網這個開放體系中，任務企業均可以集成第三方的服務來提高本身的服務能力，同時也能夠將本身的服務能力開放給第三方提供被集成的能力，從而構建一個開放、雙贏的生態體系。要開放、也要連接，而這繞不開的一個點就是認證受權問題。統一身份認證服務應運而生，各企業再也不拘泥於內部的身份統一，在企業服務與企業服務之間創建安全可靠的連接，可以增強信息的流通、服務能力的提高，促進企業生態的發展。