|
引言： 目錄： 一、簡(jiǎn)介 二、用戶認(rèn)證 三、網(wǎng)關(guān)及API調(diào)用認(rèn)證 四、系統(tǒng)間認(rèn)證和系統(tǒng)內(nèi)認(rèn)證 五、總結(jié) 一、簡(jiǎn)介 首先，我們來看一下什么是認(rèn)證？ 認(rèn)證是確認(rèn)當(dāng)前聲稱為 xxx 的用戶確實(shí)為 xxx 本身。 用戶可以是人、系統(tǒng)、應(yīng)用或任意調(diào)用者。 最簡(jiǎn)單的認(rèn)證，就是用戶名密碼登錄，常見的認(rèn)證方式還有：手機(jī)驗(yàn)證碼、生物識(shí)別（指紋，虹膜識(shí)別、面部識(shí)別等）、U 盾、數(shù)字證書。 關(guān)于認(rèn)證更加詳盡的定義和認(rèn)證方式，請(qǐng)參見維基百科：https://en./wiki/Authentication 那在微服務(wù)系統(tǒng)中有哪些地方需要進(jìn)行認(rèn)證管理(不包括DevOps中的認(rèn)證)呢？如下圖所示： 凡是存在交互的地方均需要進(jìn)行認(rèn)證：
可以將它們分為如下三類：
下面我們將對(duì)這三類認(rèn)證，分別做詳細(xì)的介紹。 二、用戶認(rèn)證 微服務(wù)架構(gòu)中會(huì)存在很多系統(tǒng)，而且系統(tǒng)間的切換也需要無縫進(jìn)行，例如一個(gè)前端框架中可能會(huì)集成多個(gè)系統(tǒng)的調(diào)用。此時(shí)，我們自然而然的會(huì)想到單點(diǎn)登錄，單點(diǎn)登錄早在已存在。但微服務(wù)中的單點(diǎn)登錄與傳統(tǒng)的單點(diǎn)登錄有一定的差異。 下面這幅圖描述傳統(tǒng)的基于 Session 的單點(diǎn)登錄。 用戶的授權(quán)信息（例如角色，可訪問資源等）保存在應(yīng)用的 session 中，瀏覽器與應(yīng)用系統(tǒng)之間基于sessionID 關(guān)聯(lián)，相同應(yīng)用的集群使用緩存（如 Redis、memcached 等），或基于 session 復(fù)制來進(jìn)行共享 session 信息。 但是微服務(wù)系統(tǒng)中，api 的調(diào)用都是 stateless，沒有狀態(tài)信息，如下圖所示： 用戶的授權(quán)信息通常直接封裝到 token 中，用戶在訪問應(yīng)用或系統(tǒng)的時(shí)候，攜帶上 token，應(yīng)用或系統(tǒng)直接從 token 中反解出用戶的授權(quán)相關(guān)信息。 2.1.OAuth2.0與SSO OAuth2.0是授權(quán)框架，SSO 是認(rèn)證服務(wù)，但是我們可以基于 OAuth2.0實(shí)現(xiàn)SSO 認(rèn)證服務(wù)。 OAuth2.0本身不提供認(rèn)證服務(wù)，但是具有足夠的擴(kuò)展空間，讓我們來擴(kuò)展，例如基于 OAuth2.0 的OIDC。 2.2.基于OAuth2.0的單點(diǎn)登錄上圖所示,為一個(gè)基于OAuth2.0的 SSO的流程，整體流程基本上和普通的 SSO 一致，所不同的是，存儲(chǔ) app Cookie 的時(shí)候，保存的是經(jīng)過應(yīng)用或系統(tǒng)處理和加密過的 token，用戶后續(xù)請(qǐng)求，帶上加密后的 token，在 app 后端直接解密和抽取出用戶相關(guān)的授權(quán)信息，流程如下: 1. 用戶訪問app1.com 2. 由于用戶沒有登錄，因此跳轉(zhuǎn)到 iam.com 3. 用戶在 iam.com的登錄頁面，輸入用戶名和密碼，確認(rèn)提交，iam 校驗(yàn)成功后 4. 在瀏覽器端寫入瀏覽器cookie 5. 重定向到 app1.com，并獲取 token(此處獲取 token流程，與OAuth2.0協(xié)議有關(guān)) 6.app1.com檢查 token 有效性 7. 重定向用戶訪問頁面，并存儲(chǔ) app1.com的token 到app1.com的cookie 中 8. 用戶訪問app2.com 9.app2.com重定向到iam.com 10.iam.com此時(shí)發(fā)現(xiàn) cookie 內(nèi)已經(jīng)有認(rèn)證的token（或 session） 信息 11. 直接重定向到app2.com,并獲得 token 信息 12.app2.com驗(yàn)證 token 信息 13. 重定向到app2.com,并保存app2.com的 token 信息到 app2.com 的 cookie 中 2.3.Token 通常情況下，IAM會(huì)使用類似jwt 這樣的協(xié)議去封裝用戶信息和授權(quán)相關(guān)信息。 App需要對(duì) Token 進(jìn)行處理，加密后再存入到瀏覽器 cookie 中去。 2.4.單點(diǎn)退出 傳統(tǒng)的 SLO 是由 SSO 服務(wù)器通知每一個(gè)應(yīng)用系統(tǒng)，強(qiáng)制 session失效。 在微服務(wù)系統(tǒng)中，由于系統(tǒng)或應(yīng)用間調(diào)用是無狀態(tài)的,因此 IAM 無法通知每個(gè)應(yīng)用退出指定用戶。 但是，我們可以利用 OAuth2.0 的refreshToken 機(jī)制,當(dāng)app去refreshToken的時(shí)候，通知應(yīng)用退出。 首先，當(dāng)一個(gè)應(yīng)用點(diǎn)擊退出時(shí)，應(yīng)用先通知 IAM 清除當(dāng)前用戶在 IAM 上的session 和所有相關(guān)的認(rèn)證 Token 信息。 當(dāng)其他應(yīng)用進(jìn)行refreshToken的時(shí)候，返回用戶已經(jīng)退出的信息，要求用戶重新登錄。 注意： 這樣的單點(diǎn)退出不是實(shí)時(shí)的，會(huì)存在一個(gè)誤差（accessToken的有效時(shí)間） 2.5.用戶登錄控制基于OAuth2.0 實(shí)現(xiàn)的 SSO，可以對(duì)用戶是否可以登錄某一系統(tǒng)進(jìn)行控制。 在系統(tǒng)去交換/獲取 Token的時(shí)候，判斷用戶是否具有訪問指定系統(tǒng)的權(quán)限。 特點(diǎn)：可在線控制用戶訪問或拒絕訪問指定系統(tǒng)。 缺點(diǎn)：同樣不是實(shí)時(shí)的，會(huì)存在一個(gè)誤差（accessToken的有效時(shí)間）。 2.6.在線用戶管理
當(dāng)用戶登錄IAM 的時(shí)候，IAM 可以跟蹤和控制用戶登錄的超時(shí)。 當(dāng)用戶使用 SSO“登錄”一個(gè)應(yīng)用或系統(tǒng)時(shí)，會(huì)記錄用戶的 Token 信息。這里需要說明一下，用戶的同一賬號(hào)，有時(shí)候是可以同時(shí)在不通的機(jī)器上進(jìn)行登錄的。 通過控制“用戶登錄和系統(tǒng)授權(quán)”信息，來強(qiáng)制當(dāng)前用戶下線和統(tǒng)計(jì)在線用戶信息和登錄系統(tǒng)的信息。 三、網(wǎng)關(guān)及 API 調(diào)用認(rèn)證 網(wǎng)關(guān)管理員 網(wǎng)關(guān)管理員訪問網(wǎng)關(guān)系統(tǒng)，屬于用戶認(rèn)證，則可以使用用戶認(rèn)證的方式來進(jìn)行認(rèn)證 API 調(diào)用
API調(diào)用認(rèn)證可以綁定一組 API 到一個(gè)隨機(jī)的 Token，使用Token 來唯一標(biāo)識(shí)其綁定的一組 API 的訪問權(quán)限，我們可以在系統(tǒng)中對(duì)這個(gè) token 進(jìn)行分配配額和 API 調(diào)用的限制； 注意：Token本身是不綁定調(diào)用者，所以，任何擁有 token 的應(yīng)用都可以進(jìn)行訪問。 網(wǎng)關(guān)調(diào)用系統(tǒng) 網(wǎng)關(guān)調(diào)用系統(tǒng)，可以按照系統(tǒng)間的調(diào)用進(jìn)行處理，請(qǐng)參見隨后章節(jié)，系統(tǒng)間的調(diào)用。 四、系統(tǒng)間認(rèn)證和系統(tǒng)內(nèi)認(rèn)證 系統(tǒng)間認(rèn)證和系統(tǒng)內(nèi)認(rèn)證，實(shí)際上都是應(yīng)用之間的調(diào)用，所不同的是，前者的應(yīng)用是跨系統(tǒng)的，后者是在同一個(gè)系統(tǒng)內(nèi)。
應(yīng)用間的調(diào)用認(rèn)證，可以對(duì)系統(tǒng)信息、應(yīng)用信息、調(diào)用相關(guān)信息進(jìn)行編碼（jwt） 加密（jwe）， 然后再通過http header的方式傳輸?shù)较掠蜗到y(tǒng)或應(yīng)用，下游系統(tǒng)或應(yīng)用通過解密，獲得調(diào)用者的相關(guān)信息，對(duì)其進(jìn)行認(rèn)證處理。 五、總結(jié) 認(rèn)證管理有很多不同的方式，上面我所說的是一些常見的處理手段，也是普元統(tǒng)一認(rèn)證管理平臺(tái)IAM目前使用到的一些技術(shù)手段。
以上我們重點(diǎn)介紹了用戶管理、SSO、SLO、網(wǎng)關(guān)及 API 調(diào)用認(rèn)證、系統(tǒng)間和系統(tǒng)內(nèi)認(rèn)證及相關(guān)的處理技術(shù)。 當(dāng)然，認(rèn)證管理還有很多其他的處理手段和相關(guān)協(xié)議，比如認(rèn)證授權(quán)協(xié)議： OIDC、SAML等，這里就不贅述了，有機(jī)會(huì)再和大家探討。  參考內(nèi)容 微服務(wù)架構(gòu)下的安全認(rèn)證與鑒權(quán) https:///blog/what-is-and-how-does-single-sign-on-work/ https://searchsecurity./definition/single-sign-on https://en./wiki/Single_sign-on https://spin./2016/05/30/openid-oauth-saml/ https://www./blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/ https://blog./oauth-sso 精選提問： 問1：auth2tocken 如何驗(yàn)證有效性和合法性？跨服務(wù)的auth2如何驗(yàn)證？ 答：OAuth2 的 token 驗(yàn)證有幾種方式： jwt 使用數(shù)字簽名進(jìn)行驗(yàn)證;jwt，jwk中都有其詳細(xì)的描述，可以參見協(xié)議的詳細(xì)內(nèi)容，跨服務(wù)的驗(yàn)證也是同樣的驗(yàn)證方式。 問2：staleless token方案，后臺(tái)沒有session嗎？那當(dāng)前登錄的附加信息如何處理？ 答：staleless token后端是沒有 session，否則也就不是 stateless，附加信息一般都是編碼到 token 中去的，具體大家可以參見jwt協(xié)議相關(guān)的內(nèi)容：https:/// 問3：如果一個(gè)大系統(tǒng)內(nèi)部有微服務(wù)系統(tǒng)、其它普通的非微服務(wù)系統(tǒng)，還能否使用您所講的微服務(wù)token機(jī)制進(jìn)行統(tǒng)一認(rèn)證？如果可以，需要怎樣做？ 答：是可以的，至于怎么做，這個(gè)需要您的非微服務(wù)系統(tǒng)是具體的安全框架是怎么樣的，比如：spring security，apache shiro 都可以通過自定義 Filter 的方式來實(shí)現(xiàn)。 問4：IAM系統(tǒng)哪里可以體驗(yàn)？ 答：IAM 會(huì)和我們近期發(fā)布的 Platform 8LA 版本一并發(fā)布，請(qǐng)隨后持續(xù)關(guān)注我們的產(chǎn)品發(fā)布動(dòng)態(tài)，謝謝！ |
|
|
