程式設計師在為某個應用系統編寫接入其它應用系統的程式**的時候，常常為了使用者認證大傷腦筋：1) 讓終端使用者頻繁登入? 似乎是乙個讓使用者很難接受的解決方案。2) 在**中內建使用者名稱和密碼? **需要隨使用者和密碼的變化經常維護，同時在很多場合下，使用者名稱和密碼對於程式設計師來說可能是不可見的。
如何解決這一問題呢？經過討論，決定開發乙個統一身份認證服務，以解決這一應用整合中碰到的使用者認證的問題。這個服務需要達到以下功能和目標：
支援web services技術框架，使得在對各個應用系統實施基於web services的應用整合(eai/b2bi)的時候能夠使用這個統一身份認證服務進行身份認證。
方便使用，能夠盡可能地利用現有系統的身份認證模組以及現有的使用者設定和許可權設定，盡量保護現有的投資，減少重新的使用者設定和許可權設定的費用，同時避免對現有系統進行大規模的修改。
具有良好的擴充套件性和可整合性，不僅能支援現有的應用系統及其現有的使用者系統，當有新的企業應用被部署或開發的時候，這個統一身份認證服務可以作為它的身份認證模組的形式工作，也就是說，新的企業應用可以不自帶使用者系統，可以通過整合該服務的形式來實現等價的功能。
應當具備靈活和方便的使用模式，使用者可以通過多種方式自由地使用該統一身份認證服務。
根據這個統一身份認證服務的目標和初步的功能定義，我們將這個服務設計如下：
figure 1. 統一身份認證服務
該服務主要需要具備三項功能：
使用者註冊：使用者在統一身份認證服務中註冊帳號，以後這個帳號可以在所有使用統一身份認證服務的應用系統中使用。
帳號關聯：如果使用者之前已經在相關的應用系統中擁有帳號，同時也已經設定了相應的許可權，那麼使用者能夠將這些應用系統的帳號與統一身份認證服務的帳號進行關聯，使得使用者登入統一身份認證服務之後，就能夠自動使用相關的應用系統使用者來訪問應用系統。
使用者認證：為應用系統提供使用者身份認證，兼顧兩個應用方式：
按照以上的功能描述，我們可以認為統一身份認證服務中需要考慮的實體可以使用下圖來表示：
figure 2. 統一身份認證服務的資料實體
使用者(user)：即統一身份認證服務的使用者；
會話(session)：當使用者登入統一身份認證服務後，即建立了乙個活躍的會話，並獲得會話的認證令牌，在這個會話中，使用者可以使用會話的認證令牌訪問各種應用系統。
使用者註冊(包括使用者更新註冊資訊)的流程可以使用下圖來表示。其中主要包含了兩個流程：新使用者註冊和使用者更新註冊資訊。
figure 3. 使用者註冊流程
新使用者註冊：
使用者向統一身份認證服務發出新使用者註冊請求
服務查詢使用者註冊庫，如果該使用者可以註冊(沒有同名id等違背約束條件的情況發生)，那麼將該使用者的資訊儲存到使用者註冊庫中。
當儲存完畢後，統一身份認證服務響應使用者，註冊完成。
使用者更新註冊資訊：
使用者向統一身份認證服務發出使用者註冊資訊更新請求。
服務查詢使用者註冊庫，如果該使用者資訊可以更新(有該id存在，同時提供的密碼也是正確的等等)，那麼將該使用者的資訊將在使用者註冊庫中更新。
當儲存完畢後，統一身份認證服務響應使用者，更新完成。
帳號關聯操作可以使用下圖來表示。圖中僅包含乙個登記新的帳號關聯的操作，相關的修改、刪除操作被省略了，有興趣的讀者可以自行給出。
figure 4. 使用者關聯流程
登記新的帳號關聯：
使用者向統一身份認證服務發出帳號關聯註冊請求，使用者提供了應用系統的標識a，同時提供了可以在該應用系統中使用的使用者資訊(可能包含使用者名稱和密碼等)。
服務首先向該應用系統a徵詢，使用者資訊是否合法。如果合法則響應服務。
如果收到合法響應，那麼服務就將這個帳號關聯註冊資訊儲存到使用者註冊庫中，以後該使用者登入統一身份認證服務之後，就能夠使用相應的應用系統a。
當註冊庫完成儲存操作後，統一身份認證服務響應使用者，註冊完成。
統一身份認證服務的乙個基本應用模式是以應用系統的身份認證元件的形式工作，在這個應用模式下，主導地位的是應用系統。在這種情況下，應用系統自身沒有使用者系統，因此本模式下涉及的帳號一定是統一身份認證服務的使用者帳號。
figure 5. 身份認證元件模式流程
流程描述如下：(僅描述正常流程)
使用者使用在統一認證服務註冊的使用者名稱和密碼(也可能是其他的授權資訊，比如數字簽名等)登陸應用系統a
應用系統a，將使用者名稱和密碼連同自己的標識(應用系統a的標識)一起**給統一認證服務，要求統一認證服務完成登入操作。
統一認證服務核查自己的應用系統註冊庫(使用uddi registry，我將在後面解釋為什麼使用uddi registry)看看應用系統a是否已經是統一認證服務的使用者系統。同時在使用者註冊庫中核查由應用系統a**過來的使用者名稱和密碼。
待核查完畢後，統一認證服務響應應用系統a，登入完成。
應用系統a建立乙個系統會話(session，系統a自己的機制)，並將應用系統a自己的許可權令牌返回給使用者，以後使用者端可以通過這個許可權令牌持續訪問應用系統a，直至登出系統或是會話超時。
統一認證模式是以統一身份認證服務為核心的服務使用模式。使用者登入統一身份認證服務後，即可使用所有支援統一身份認證服務的應用系統。
figure 6. 統一認證模式流程
流程描述如下：(僅描述正常流程)
使用者使用在統一認證服務註冊的使用者名稱和密碼(也可能是其他的授權資訊，比如數字簽名等)登陸統一認證服務；
統一認證服務建立了乙個會話，同時將與該會話關聯的訪問認證令牌返回給使用者；
使用者使用這個訪問認證令牌訪問某個支援統一身份認證服務的應用系統；
該應用系統將訪問認證令牌傳入統一身份認證服務，認證訪問認證令牌的有效性；
統一身份認證服務確認認證令牌的有效性；
應用系統接收訪問，並返回訪問結果，如果需要提高訪問效率的話，應用系統可選擇返回其自身的認證令牌已使得使用者之後可以使用這個私有令牌持續訪問。
此外，關於訪問認證令牌的失效，有兩個策略，乙個是由使用者主動發起宣告，宣告其擁有的訪問認證令牌不再有效，這類似登出的操作，另乙個是使用者一段時間內沒有使用這個認證令牌，認證令牌自動失效，這類似超時的處理。
在internet應用環境下，安全性和信任的重要性是顯而易見的，對於商用系統而言，避免非法訪問和入侵是他所需要考慮的幾個重要問題之一，沒有比商用資料丟失或是商用系統被違規使用更糟糕的了。
在信任**模式下，乙個組織可以為他所有需要提供安全信任保障的應用系統設定乙個統一身份認證服務，對這些應用系統的訪問全部由統一身份認證服務**。
figure 7. 信任**模式流程
流程描述如下：(僅描述正常流程)
使用者使用在統一認證服務註冊的使用者名稱和密碼(也可能是其他的授權資訊，比如數字簽名等)登陸統一認證服務；
統一認證服務建立了乙個會話，同時將與該會話關聯的訪問認證令牌返回給使用者；
使用者使用這個訪問認證令牌訪問某個支援統一身份認證服務的應用系統，不過使用者並不將請求訊息直接交給應用系統，而是傳給統一身份認證服務，在訊息中標識了最終的應用系統的id。
統一認證服務訪問應用系統註冊庫(uddi registry)，獲取了應用系統的訪問入口(統一認證服務可以將這個訪問入口快取在本地，以減少以後與應用系統註冊庫的互動次數)。並確認這個應用系統的確是支援統一身份認證服務的；
統一認證服務將請求訊息**給指定的應用系統，如果該應用系統使用自己的使用者系統的話，那麼該訊息應當包含了預先定義好的相關聯的使用者名稱和密碼等。
應用系統將請求結果返回給統一認證服務，最後統一認證服務將響應訊息返回給使用者，完成呼叫。
在該模式下，所有應用系統僅接收來自統一認證服務的訪問請求，這樣，解決方案提供商可以將主要的安全方面的投入部署在統一認證服務那端。
以上內容為 鏈結內容中的一段節選
統一認證系統（一）
每個系統都需要識別操作者的身份，並根據其不同的身份，分配一定的許可權，做一些操作上的限制。隨著系統的增多，若是單獨給每個系統都設計了一套使用者資料和許可權管理的機制，並提供了使用者登入證認，雖可以解決問題，但是將會帶來和使用者賬號管理不方便，使用者資料不統一等等問題。所以，將使用者資料整合起來，進行...
統一認證系統實現要點 資源認證
許可權系統有乙個普遍的需求，即 使用者登入系統後，在瀏覽器位址列直接輸入未經授權的url，應該拒絕其訪問。目前有很多執行緒的許可權框架對這部分進行了封裝，如shiro，但是如果不想引入新框架，保持系統的輕量，該如何做呢？如何配置使用者許可權資訊讓使用者在到達每個操作行為前就判斷使用者是否有進行當前操...
身份認證系統（一）單WEB應用的身份認證
身份認證技術，也就是所謂的登入功能，是現代web系統最常見的功能之一。本系列文章就試圖為大家詳細的介紹身份認證技術。basic認證模式 basic認證模式是較早被廣泛應用的一種http標準提供的認證模式。最常見的形式之一就是在url中直接寫上使用者名稱密碼向伺服器提供身份 在basic模式之中，每次...