Web服務實戰：統一身份認證服務...

　　每個應用系統都有其自身的用戶系統和認證方式。程序員在為某個應用系統編寫接入其它應用系統的程序代碼時，常常為用戶認證大傷腦筋。問題主要表現在以下幾方面：

　　1．讓最終用戶頻繁登錄? 但這似乎是一個讓用戶很難接受的解決方案。

　　2．在代碼中內置用戶名和密碼? 　　但代碼需要隨用戶和密碼的變化經常維護，同時在很多場合下，用戶名和密碼對于程序員來說是不可見的。

如何解決這一問題呢？我們從目前和未來的應用發展趨勢判斷認為，應當開發一個統一身份認證服務，以解決這一應用集成中碰到的用戶認證問題。這個服務需要達到以下功能和目標：

　　1. 支持Web服務技術框架，使得在對各個應用系統實施基于Web服務的應用集成(EAI/B2Bi)的時候，能夠使用這個統一身份認證服務，進行身份認證。

　　2. 方便使用，能夠盡可能地利用現有系統的身份認證模塊及現有的用戶設置和權限設置，盡量保護現有的投資，減少新用戶設置和權限設置的費用。同時避免對現有系統進行大規模的修改。

　　3. 具有良好的擴展性和可集成性，不僅能支持現有的應用系統及用戶系統，當有新的企業應用被部署或開發的時候，這個統一身份認證服務還可以作為其身份認證模塊的形式工作。也就是說，新的企業應用可以不自帶用戶系統，可以通過集成該服務的形式來實現等價的功能。

　　4. 應當具備靈活和方便的使用模式，使用者可以通過多種方式自由地使用該統一身份認證服務。

　　解決方案

　　根據這個統一身份認證服務的目標和初步的功能定義，將這個服務設計為圖1所示。

　　該服務主要需要具備三項功能：

　　1. 用戶注冊，用戶在統一身份認證服務中注冊賬號。以后這個賬號可以在所有使用統一身份認證服務的應用系統中使用。

　　2. 賬號關聯。如果用戶之前已經在相關的應用系統中擁有賬號，同時也已經設置了相應的權限，那么用戶能夠將這些應用系統的賬號與統一身份認證服務的賬號進行關聯，使得用戶登錄統一身份認證服務之后，就能夠自動使用相關的應用系統用戶來訪問應用系統。

　　3. 用戶認證。為應用系統提供用戶身份認證，應兼顧以下兩個應用方式：

　　◆ 應用系統使用統一身份認證服務作為它的用戶系統，用戶與應用系統進行交互，并進行登錄操作，應用系統將用戶提供的用戶名、密碼等轉發給統一身份認證服務以檢驗其是否通過授權。

　　◆ 用戶首先登錄統一身份認證服務，并獲取權限令牌，然后可以使用這個權限令牌訪問其它應用系統，應用系統接收該權限令牌時應當與統一身份認證服務進行交互，以檢驗訪問的合法性。

按照以上的功能描述，可以確定統一身份認證服務中需要考慮的實體包括：

　　1. 用戶(User)，即統一身份認證服務的用戶。

　　2. 賬號(Account)，即應用系統的賬號，與統一身份認證服務的用戶相關聯。一個用戶可以關聯多個賬號。

　　3. 應用系統(Application)，使用統一身份認證服務的應用系統。

　　4. 會話(Session)，當用戶登錄統一身份認證服務后，即創建了一個活躍的會話，并獲得會話的認證令牌。在這個會話中，用戶可以使用會話的認證令牌訪問各種應用系統。

　　用戶注冊

　　用戶注冊(包括用戶更新注冊信息)的流程主要包含兩個流程：新用戶注冊和用戶更新注冊信息。

　　賬號關聯

　　賬號關聯操作可以使用圖2所示的形式來表示。圖2中僅包含一個登記新的賬號關聯的操作，相關的修改、刪除操作已被省略。

　　登記新的賬號關聯：

　　1. 用戶向統一身份認證服務發出賬號關聯注冊請求，用戶提供了應用系統的標識A，同時提供了可以在該應用系統中使用的用戶信息(如用戶名和密碼等)。

　　2. 服務首先向該應用系統A征詢，用戶信息是否合法。如果合法則響應服務。

　　3. 如果收到合法響應，那么服務就將這個賬號關聯注冊信息保存到用戶注冊庫中，在該用戶登錄統一身份認證服務之后，就能夠使用相應的應用系統A。

　　4. 當注冊庫完成保存操作后，統一身份認證服務響應用戶，最后注冊完成。

　　身份認證組件模式

　　統一身份認證服務的一個基本應用模式是以應用系統的身份認證組件的形式工作。在這個應用模式下，處在主導地位的是應用系統。在該情況下，應用系統自身沒有用戶系統，因此模式下涉及的賬號一定是統一身份認證服務的用戶賬號。

　　流程描述如下 (如圖3，僅描述正常流程) ：

　　1. 用戶使用在統一認證服務注冊的用戶名和密碼(也可能是其它授權信息，比如數字簽名等)登陸應用系統A。

　　2. 應用系統A將用戶名和密碼連同自己的標識(應用系統A的標識)一起轉發給統一認證服務，要求統一認證服務完成登錄操作。

　　3. 統一認證服務核查自己的應用系統注冊庫(使用UDDI Registry)，看看應用系統A是否已經是統一認證服務的用戶系統。同時在用戶注冊庫中核查由應用系統A轉發過來的用戶名和密碼。

　　4. 待核查完畢后，統一認證服務響應應用系統A，登錄完成。

　　5. 應用系統A創建一個系統會話(Session，系統A自己的機制)，并將應用系統A自己的權限令牌返回給用戶。以后用戶端可以通過這個權限令牌持續訪問應用系統A，直至登出系統或是會話超時。

　　統一認證模式

　　統一認證模式是以統一身份認證服務為核心的服務使用模式。用戶登錄統一身份認證服務后，即可使用所有支持統一身份認證服務的應用系統。

　　流程描述如下 (如圖4，僅描述正常流程)：

　　1. 用戶使用在統一認證服務注冊的用戶名和密碼(也可能是其他的授權信息，比如數字簽名等)登陸統一認證服務；

　　2. 統一認證服務創建了一個會話，同時將與該會話關聯的訪問認證令牌返回給用戶；

　　3. 用戶使用這個訪問認證令牌訪問某個支持統一身份認證服務的應用系統；

　　4. 該應用系統將訪問認證令牌傳入統一身份認證服務，認證訪問認證令牌的有效性；

　　5. 統一身份認證服務確認認證令牌的有效性；

　　6. 應用系統接收訪問，并返回訪問結果，如果需要提高訪問效率的話，應用系統可選擇返回其自身的認證令牌已使得用戶之后可以使用這個私有令牌持續訪問。

　　此外，關于訪問認證令牌的失效，有兩個策略：一個是由用戶主動發起聲明，聲明其擁有的訪問認證令牌不再有效，這類似注銷的操作；另一個是用戶一段時間內沒有使用這個認證令牌，認證令牌自動失效，這類似超時的處理。

　　信任代理模式

　　在Internet應用環境下，安全性和信任的重要性是顯而易見的，對于商用系統而言，避免非法訪問和入侵是他所需要考慮的幾個重要問題之一，沒有比商用數據丟失或是商用系統被違規使用更糟糕的了。

　　在信任代理模式下，一個組織可以為他所有需要提供安全信任保障的應用系統設置一個統一身份認證服務，對這些應用系統的訪問全部由統一身份認證服務代理。

　　流程描述如下(如圖5，僅描述正常流程)：

　　1. 用戶使用在統一認證服務注冊的用戶名和密碼(也可能是其他的授權信息，比如數字簽名等)登陸統一認證服務；

　　2. 統一認證服務創建了一個會話，同時將與該會話關聯的訪問認證令牌返回給用戶；

　　3. 用戶使用這個訪問認證令牌訪問某個支持統一身份認證服務的應用系統，不過用戶并不將請求消息直接交給應用系統，而是傳給統一身份認證服務，在消息中標識了最終的應用系統的ID。

　　4. 統一認證服務訪問應用系統注冊庫(UDDI Registry)，獲取了應用系統的訪問入口(統一認證服務可以將這個訪問入口緩存在本地，以減少以后與應用系統注冊庫的交互次數)，并確認這個應用系統的確是支持統一身份認證服務的。

　　5. 統一認證服務將請求消息轉發給指定的應用系統，如果該應用系統使用自己的用戶系統的話，那么該消息應當包含了預先定義好的相關聯的用戶名和密碼等。

　　6. 應用系統將請求結果返回給統一認證服務，最后統一認證服務將響應消息返回給用戶，完成調用。

　　在該模式下，所有應用系統僅接收來自統一認證服務的訪問請求。這樣，解決方案提供商可以將主要的安全方面的投入部署在統一認證服務那端。

　　使用Web服務架構

　　由于統一身份認證服務可能被應用的領域包括：

　　◆ 企業內部的各種應用

　　◆ 跨國企業的各個部門或地區分公司的各種應用

　　◆ 行業內各個企業的不同應用

　　◆ Internet上豐富的應用環境

　　無論是何種應用環境，都將面對不同的平臺、不同的系統和不同的編程環境，要能最大可能地支持所有的平臺、系統和編程環境，同時又要確保服務的實現代價保持相對固定。那么目前看來，選擇基于規范的Web服務解決方案將是最佳的選擇。