技術(shù)干貨 | 統(tǒng)一認證系統(tǒng)的高可用與業(yè)務(wù)系統(tǒng)的應(yīng)急碼設(shè)計

通過建設(shè)一套統(tǒng)一身份認證的系統(tǒng)，將用戶的登錄入口進行統(tǒng)一。企業(yè)用戶只需要知道一個地址，一套用戶名口令，進行一次認證，即可實現(xiàn)所有應(yīng)用集中訪問，可大大的提升用戶的使用體驗。

那么我們回過頭來想一想，既然用戶的訪問入口進行了統(tǒng)一，那么從架構(gòu)上來看，要是這個統(tǒng)一的入口白旗高高掛起、歇菜了，那豈不是所有的用戶都訪問不了？

上述統(tǒng)一認證系統(tǒng)的故障場景，也正是在前期技術(shù)方案交流過程中，大多數(shù)客戶都在問的問題：

1、統(tǒng)一身份認證系統(tǒng)本身架構(gòu)如何設(shè)計，以保障統(tǒng)一入口的高可用？

2、當系統(tǒng)短時間內(nèi)無法訪問的情況下，關(guān)鍵業(yè)務(wù)系統(tǒng)如何保障業(yè)務(wù)訪問的連續(xù)性？

本篇文章專門針對客戶提出的兩個問題，從系統(tǒng)本身以及業(yè)務(wù)系統(tǒng)層面兩個不同的角度對上述問題進行分析解答。

首先，針對統(tǒng)一認證系統(tǒng)的高可用架構(gòu)設(shè)計，我們主要介紹三種方案：

傳統(tǒng)高可用架構(gòu)

高可用架構(gòu)設(shè)計-示意圖

傳統(tǒng)高可用架構(gòu)設(shè)計，主要從三個方面解決統(tǒng)一身份認證系統(tǒng)的高可用問題：

● 應(yīng)用服務(wù)集群部署架構(gòu)：

統(tǒng)一身份認證系統(tǒng)作為用戶的統(tǒng)一且唯一的認證入口，同時還會承擔所有用戶的大量的請求。為解決應(yīng)用服務(wù)器的單點故障問題，我們可以通過增加應(yīng)用服務(wù)器，進行集群部署。同時，多臺服務(wù)器同時提供服務(wù)，可以降低單臺應(yīng)用服務(wù)器所承受的服務(wù)壓力，提高系統(tǒng)的服務(wù)性能，提升用戶的訪問速度。

應(yīng)用服務(wù)器前面部署負載均衡服務(wù)器調(diào)度用戶請求，根據(jù)分發(fā)策略將請求分發(fā)到多個應(yīng)用服務(wù)器節(jié)點。

當系統(tǒng)的性能達到瓶頸時，也可以采用橫向擴展應(yīng)用服務(wù)器的方式進行性能擴容。

小知識：

常用的負載均衡的選擇上，通常有硬件及軟件兩種方案：

? 硬件方案，價格比較昂貴，通常有F5、Redware等硬件產(chǎn)品；

? 軟件方案，通常使用LVS（Linux Virtual Server）、HAProxy、Nginx等方式，其中LVS工作于四層網(wǎng)絡(luò)，HAProxy可工作于四層及七層網(wǎng)絡(luò)，Nginx工作于七層網(wǎng)絡(luò)，最新版的Nginx（1.9版本后）加入了四層網(wǎng)絡(luò)的支持；

● 負載均衡HA部署架構(gòu)：

從以上應(yīng)用服務(wù)集群部署架構(gòu)上來看，雖然統(tǒng)一認證應(yīng)用服務(wù)已實現(xiàn)了集群部署，多臺服務(wù)器提供服務(wù)避免了單點故障的問題。但是負載均衡服務(wù)同樣面臨著單點故障的問題，如負載均衡服務(wù)出現(xiàn)問題，所有用戶依然無法正常訪問。

所以，對負載均衡設(shè)備進行HA高可用部署，同樣顯得很有必要：

通過將負載均衡服務(wù)進行HA高可用部署，當當前提供服務(wù)的負載均衡服務(wù)出現(xiàn)故障時，可自動將服務(wù)切換到熱備的均衡負載設(shè)備上，保障系統(tǒng)不間斷的提供服務(wù)。

● 數(shù)據(jù)服務(wù)集群部署架構(gòu)：

統(tǒng)一身份認證系統(tǒng)的數(shù)據(jù)庫，這也是必須需要解決且最為關(guān)鍵的一環(huán)，對數(shù)據(jù)庫服務(wù)進行集群部署，即可解決數(shù)據(jù)服務(wù)單點故障的問題。

在數(shù)據(jù)庫的集群部署上，根據(jù)不同的數(shù)據(jù)庫產(chǎn)品，同樣有著不同的集群技術(shù)方案，以下列舉以下主流的幾種數(shù)據(jù)庫的集群方案：

■ Oracle數(shù)據(jù)庫：采用共享存儲實現(xiàn)RAC集群方案，數(shù)據(jù)存放在一個共享存儲中，多個數(shù)據(jù)節(jié)點同時操作數(shù)據(jù)；

■ MySQL數(shù)據(jù)庫：可采用主主復(fù)制、主備復(fù)制模式，數(shù)據(jù)放在各自服務(wù)器上，通過配置的主主復(fù)制、主備復(fù)制模式實現(xiàn)數(shù)據(jù)文件的同步；

■ DB2數(shù)據(jù)庫：可提供HADR、pureScale等部署技術(shù)，其中HADR技術(shù)為雙活節(jié)點的部署模式，通過數(shù)據(jù)庫日志復(fù)制的方式實現(xiàn)節(jié)點間的數(shù)據(jù)同步，pureScale技術(shù)則為多服務(wù)節(jié)點+共享存儲的部署模式；

上述傳統(tǒng)架構(gòu)設(shè)計，企業(yè)可以通過橫向擴展的方式進行性能擴容，可以滿足大多數(shù)企業(yè)的統(tǒng)一身份認證系統(tǒng)建設(shè)需要。

微服務(wù)部署架構(gòu)

從架構(gòu)上來看，上述設(shè)計是基于傳統(tǒng)的部署方案進行架構(gòu)設(shè)計。當需要對統(tǒng)一身份進行版本發(fā)布時，往往是動一發(fā)牽全身，每次發(fā)布都需要需要發(fā)布的時間窗口，并提前對用戶進行通知。

這個問題可通過最新的微服務(wù)架構(gòu)得到緩解：

首先，通過對統(tǒng)一身份認證的服務(wù)模塊分拆為不同的微服務(wù)，包括：

? SSO模塊：提供統(tǒng)一認證服務(wù)

? Selfcare模塊：提供用戶自助服務(wù)

? IDM模塊：提供身份管理服務(wù)

? Audit模塊：提供安全審計服務(wù)

? Admin Console模塊：提供后臺管理服務(wù)

同時，后端的身份認證服務(wù)，通過API網(wǎng)關(guān)對外發(fā)布，并在API網(wǎng)關(guān)上實現(xiàn)身份認證服務(wù)相關(guān)API的權(quán)限管控，保證系統(tǒng)安全性。

異地災(zāi)備部署架構(gòu)

前面介紹的高可用部署架構(gòu)，足以滿足中小企業(yè)對統(tǒng)一身份認證系統(tǒng)建設(shè)的需要。

但針對規(guī)模較大的集團類型企業(yè)，需要考慮建設(shè)異地災(zāi)備中心的部署架構(gòu)，以保障切換到災(zāi)備中心時業(yè)務(wù)訪問的連續(xù)性。

異地災(zāi)備部署架構(gòu)-示意圖

我們建議異地災(zāi)備中心部署同等架構(gòu)的統(tǒng)一身份認證系統(tǒng)，底層數(shù)據(jù)服務(wù)采用以下同步機制：

? Oracle數(shù)據(jù)庫：采用共享存儲實現(xiàn)RAC集群方案，數(shù)據(jù)存放在一個共享存儲中，多個數(shù)據(jù)節(jié)點同時操作數(shù)據(jù)；

? MySQL數(shù)據(jù)庫：可采用主主復(fù)制、主備復(fù)制模式，數(shù)據(jù)放在各自服務(wù)器上，通過配置的主主復(fù)制、主備復(fù)制模式實現(xiàn)數(shù)據(jù)文件的同步；

? DB2數(shù)據(jù)庫：可提供HADR、pureScale等部署技術(shù)，其中HADR技術(shù)為雙活節(jié)點的部署模式，通過數(shù)據(jù)庫日志復(fù)制的方式實現(xiàn)節(jié)點間的數(shù)據(jù)同步；

接下來，我們來介紹為什么關(guān)鍵業(yè)務(wù)系統(tǒng)要做應(yīng)急逃生設(shè)計，以及如何做應(yīng)急逃生？

為什么要做應(yīng)急逃生設(shè)計？

統(tǒng)一身份認證系統(tǒng)通過上述高可用架構(gòu)設(shè)計，已實現(xiàn)系統(tǒng)本身架構(gòu)設(shè)計層面的冗余備份，在非極端情況下足以保障業(yè)務(wù)系統(tǒng)訪問的連續(xù)性。

那為什么業(yè)務(wù)系統(tǒng)還要做應(yīng)急逃生設(shè)計呢？

應(yīng)急逃生，顧名思義，就是要解決統(tǒng)一身份認證系統(tǒng)不可用的情況，用戶能夠繞過統(tǒng)一身份認證系統(tǒng)不間斷訪問業(yè)務(wù)。

應(yīng)急逃生設(shè)計的初衷主要是兩個原因：

一是為滿足特定行業(yè)，特定場景下的關(guān)鍵業(yè)務(wù)系統(tǒng)連續(xù)訪問的要求，比如銀行、機場、證券等行業(yè)生產(chǎn)類的核心業(yè)務(wù)系統(tǒng)；

二是從源頭上解決用戶統(tǒng)一訪問入口前，業(yè)務(wù)系統(tǒng)最關(guān)注的核心訴求：業(yè)務(wù)系統(tǒng)如何切換回原登錄認證入口進行認證；

如何做應(yīng)急逃生設(shè)計？

統(tǒng)一身份認證系統(tǒng)要實現(xiàn)關(guān)鍵業(yè)務(wù)系統(tǒng)的應(yīng)急逃生，需要從總體設(shè)計方案上實現(xiàn)以下要素：

? 業(yè)務(wù)系統(tǒng)切換回原登錄入口，用戶使用什么樣的密碼進行認證？

? 用戶切換回本地認證時，原系統(tǒng)用戶的應(yīng)急逃生密碼是否需要集中管理？

? 統(tǒng)一身份認證系統(tǒng)的認證體系，是否需要和業(yè)務(wù)系統(tǒng)的本地認證體系脫鉤？

? 在應(yīng)急逃生方案設(shè)計時，如何保障統(tǒng)一身份認證系統(tǒng)本身密碼的安全性？

針對上述應(yīng)急逃生設(shè)計需求的關(guān)注要素，我們引入業(yè)務(wù)系統(tǒng)“應(yīng)急碼”的設(shè)計理念，通過集中管控業(yè)務(wù)系統(tǒng)應(yīng)急碼的模式，來解決業(yè)務(wù)系統(tǒng)最為關(guān)注的核心訴求-應(yīng)急逃生。

●“應(yīng)急碼”的概念定義：

業(yè)務(wù)系統(tǒng)切換回本地認證入口時，用戶登錄原入口認證時可以使用的登錄密碼；

● 如何生成 & 如何通知 “應(yīng)急碼”：

前提：統(tǒng)一身份認證系統(tǒng)已經(jīng)集中管理關(guān)鍵業(yè)務(wù)系統(tǒng)的訪問權(quán)限；

統(tǒng)一身份管理模塊-示意圖

1. 當用戶申請開通業(yè)務(wù)系統(tǒng)的訪問權(quán)限時，由統(tǒng)一身份認證系統(tǒng)為業(yè)務(wù)系統(tǒng)生成獨立的“應(yīng)急碼”；

其中，應(yīng)急碼由獨立的密碼策略生成，以區(qū)分于現(xiàn)有賬號密碼生成機制，以保障統(tǒng)一身份認證系統(tǒng)的安全性。

2. 當業(yè)務(wù)系統(tǒng)權(quán)限成功開通后，通過郵件或者短信通知的機制，告知用戶該業(yè)務(wù)系統(tǒng)的“應(yīng)急碼”，以確保應(yīng)急碼可以通知到最終用戶。

備注：

當用戶申請多個業(yè)務(wù)系統(tǒng)權(quán)限時，上述應(yīng)急碼生成與通知機制就可以保障各個業(yè)務(wù)系統(tǒng)應(yīng)急碼的不同，間接保障各自關(guān)鍵業(yè)務(wù)系統(tǒng)的安全性。

● 用戶如何使用“應(yīng)急碼”：

應(yīng)急逃生場景-示意圖

逃生切換前提：

IAM系統(tǒng)出現(xiàn)不能訪問情況，短時間內(nèi)無法恢復(fù)統(tǒng)一認證服務(wù)；

應(yīng)急碼如何使用：

a) 業(yè)務(wù)管理員手動切換回本地緊急認證模式，為用戶登錄提供應(yīng)急認證服務(wù)；

b) 用戶需要使用應(yīng)用賬號和應(yīng)急登錄碼進行登錄認證；

c) 業(yè)務(wù)系統(tǒng)認證成功后，用戶可以正常使用業(yè)務(wù)系統(tǒng)；