微服務系統之認證管理

引言：

微服務大行其道，微服務安全也是很是熱門的話題。本文向你們分享微服務系統中認證管理相關技術。其中包括用戶認證、網關和 API 認證、系統間和系統內的認證，以及咱們的統一認證管理系統 IAM。

目錄：
1、簡介
2、用戶認證
3、網關及API調用認證
4、系統間認證和系統內認證
5、總結

1、簡介

首先，咱們來看一下什麼是認證？

認證是確認當前聲稱爲 xxx 的用戶確實爲 xxx 自己。

用戶能夠是人、系統、應用或任意調用者。

最簡單的認證，就是用戶名密碼登陸，常見的認證方式還有：手機驗證碼、生物識別（指紋，虹膜識別、面部識別等）、U 盾、數字證書。

關於認證更加詳盡的定義和認證方式，請參見維基百科：https://en.wikipedia.org/wiki/Authentication

那在微服務系統中有哪些地方須要進行認證管理(不包括DevOps中的認證)呢？以下圖所示：

凡是存在交互的地方均須要進行認證：

用戶訪問系統

系統調用網關

網關調用系統

系統內應用之間的調用

系統間的調用

能夠將它們分爲以下三類：

用戶認證

系統間及系統內認證

網關及 API 調用認證

下面咱們將對這三類認證，分別作詳細的介紹。

2、用戶認證

微服務架構中會存在不少系統，並且系統間的切換也須要無縫進行，例如一個前端框架中可能會集成多個系統的調用。此時，咱們天然而然的會想到單點登陸，單點登陸早在已存在。但微服務中的單點登陸與傳統的單點登陸有必定的差別。

下面這幅圖描述傳統的基於 Session 的單點登陸。

用戶的受權信息（例如角色，可訪問資源等）保存在應用的 session 中，瀏覽器與應用系統之間基於sessionID 關聯，相同應用的集羣使用緩存（如 Redis、memcached 等），或基於 session 複製來進行共享 session 信息。

可是微服務系統中，api 的調用都是 stateless，沒有狀態信息，以下圖所示：

用戶的受權信息一般直接封裝到 token 中，用戶在訪問應用或系統的時候，攜帶上 token，應用或系統直接從 token 中反解出用戶的受權相關信息

2.1.OAuth2.0與SSO

OAuth2.0是受權框架，SSO 是認證服務，可是咱們能夠基於 OAuth2.0實現SSO 認證服務。

OAuth2.0自己不提供認證服務，可是具備足夠的擴展空間，讓咱們來擴展，例如基於 OAuth2.0 的OIDC。

2.2.基於OAuth2.0的單點登陸

上圖所示,爲一個基於OAuth2.0的 SSO的流程，總體流程基本上和普通的 SSO 一致，所不一樣的是，存儲 app Cookie 的時候，保存的是通過應用或系統處理和加密過的 token，用戶後續請求，帶上加密後的 token，在 app 後端直接解密和抽取出用戶相關的受權信息，流程以下:

1. 用戶訪問app1.com
2. 因爲用戶沒有登陸，所以跳轉到 iam.com
3. 用戶在 iam.com的登陸頁面，輸入用戶名和密碼，確認提交，iam 校驗成功後
4. 在瀏覽器端寫入瀏覽器cookie
5. 重定向到 app1.com，並獲取 token(此處獲取 token流程，與OAuth2.0協議有關)
6.app1.com檢查 token 有效性
7. 重定向用戶訪問頁面，並存儲 app1.com的token 到app1.com的cookie 中
8. 用戶訪問app2.com
9.app2.com重定向到iam.com
10.iam.com此時發現 cookie 內已經有認證的token（或 session） 信息
11. 直接重定向到app2.com,並得到 token 信息
12.app2.com驗證 token 信息
13. 重定向到app2.com,並保存app2.com的 token 信息到 app2.com 的 cookie 中

2.3.Token

一般狀況下，IAM會使用相似jwt 這樣的協議去封裝用戶信息和受權相關信息。

App須要對 Token 進行處理，加密後再存入到瀏覽器 cookie 中去。

2.4.單點退出

傳統的 SLO 是由 SSO 服務器通知每個應用系統，強制 session失效。

在微服務系統中，因爲系統或應用間調用是無狀態的,所以 IAM 沒法通知每一個應用退出指定用戶。

可是，咱們能夠利用 OAuth2.0 的refreshToken 機制,當app去refreshToken的時候，通知應用退出。

首先，當一個應用點擊退出時，應用先通知 IAM 清除當前用戶在 IAM 上的session 和全部相關的認證 Token 信息。

當其餘應用進行refreshToken的時候，返回用戶已經退出的信息，要求用戶從新登陸。

注意：這樣的單點退出不是實時的，會存在一個偏差（accessToken的有效時間）

2.5.用戶登陸控制

基於OAuth2.0 實現的 SSO，能夠對用戶是否能夠登陸某一系統進行控制。

在系統去交換/獲取 Token的時候，判斷用戶是否具備訪問指定系統的權限。

特色：可在線控制用戶訪問或拒絕訪問指定系統。

缺點：一樣不是實時的，會存在一個偏差（accessToken的有效時間）。

2.6.在線用戶管理

當用戶登陸IAM 的時候，IAM 能夠跟蹤和控制用戶登陸的超時。

當用戶使用 SSO「登陸」一個應用或系統時，會記錄用戶的 Token 信息。這裏須要說明一下，用戶的同一帳號，有時候是能夠同時在不通的機器上進行登陸的。

經過控制「用戶登陸和系統受權」信息，來強制當前用戶下線和統計在線用戶信息和登陸系統的信息。

3、網關及 API 調用認證

網關管理員

網關管理員訪問網關係統，屬於用戶認證，則可使用用戶認證的方式來進行認證

API 調用

API調用認證能夠綁定一組 API 到一個隨機的 Token，使用Token 來惟一標識其綁定的一組 API 的訪問權限，咱們能夠在系統中對這個 token 進行分配配額和 API 調用的限制；

注意：Token自己是不綁定調用者，因此，任何擁有 token 的應用均可以進行訪問。

網關調用系統

網關調用系統，能夠按照系統間的調用進行處理，請參見隨後章節，系統間的調用。

4、系統間認證和系統內認證

系統間認證和系統內認證，實際上都是應用之間的調用，所不一樣的是，前者的應用是跨系統的，後者是在同一個系統內。

應用間的調用認證，能夠對系統信息、應用信息、調用相關信息進行編碼（jwt） 加密（jwe）， 而後再經過http header的方式傳輸到下游系統或應用，下游系統或應用經過解密，得到調用者的相關信息，對其進行認證處理。

 

5、總結

認證管理有不少不一樣的方式，上面我所說的是一些常見的處理手段，也是普元統一認證管理平臺IAM目前使用到的一些技術手段。

（IAM功能結構圖）

（IAM部署結構圖）

以上咱們重點介紹了用戶管理、SSO、SLO、網關及 API 調用認證、系統間和系統內認證及相關的處理技術。

固然，認證管理還有不少其餘的處理手段和相關協議，好比認證受權協議： OIDC、SAML等，這裏就不贅述了，有機會再和你們探討。

 

參考內容

https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/

https://searchsecurity.techtarget.com/definition/single-sign-on

https://en.wikipedia.org/wiki/Single_sign-on

https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/

https://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/

https://blog.heroku.com/oauth-sso

https://mp.weixin.qq.com/s/x0CZpovseOuofTA_lw0HvA

 

關於做者：虎振東，普元資深軟件工程師，8年軟件開發設計經驗，曾在歌華數媒架構設計開發多個廣電和移動互聯網融合項目，普元 EOS 8微服務平臺核心。

關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享