企業(yè)統(tǒng)一身份認證

WebServiceCaseStudy:統(tǒng)一身份認證服務(wù)柴曉路( )CIO,DealEasy簡介：本文是WebServiceCaseStudy系列文章的第四篇。在這篇文章中，我將圍繞一個多應(yīng)用環(huán)境下統(tǒng)一認證服務(wù)組件的架構(gòu)展開討論，探討如何利用Web服務(wù)所帶來的好處，實現(xiàn)跨平臺跨應(yīng)用的統(tǒng)一身份識別和權(quán)限認證。同時將其拓展到多種應(yīng)用模式中去，包括Internet公用服務(wù)、行業(yè)電子商務(wù)環(huán)境統(tǒng)一認證以及企業(yè)內(nèi)部應(yīng)用集成等。標記本文！發(fā)布日期：2002年8月01日級別：初級訪問情況135次瀏覽建議：0(添加評論)5LLLLL平均分(共1個評分)應(yīng)用背景以下描述中使用的地名、機構(gòu)名和系統(tǒng)名稱純屬虛構(gòu)，但是是從具體應(yīng)用中抽象出來的。GeneralBusiness是一家生產(chǎn)和銷售多種家用電器的跨國企業(yè)。GeneralBusiness一直注重利用新興的計算機技術(shù)來改善和加強公司的自動化管理。多年來，尾隨各種技術(shù)的發(fā)展，GeneralBusiness應(yīng)業(yè)務(wù)的需要，實施和部署了企業(yè)資源規(guī)劃(ERP)、客戶關(guān)系管理(CRM)、供應(yīng)鏈管理(SCM)以及企業(yè)門戶(EnterprisePortal)等多種商業(yè)應(yīng)用，這些商業(yè)應(yīng)用分別解決了企業(yè)在不同方面的需求，起到了相當?shù)纳虡I(yè)成效。然而，隨著業(yè)務(wù)和技術(shù)的發(fā)展，以自包含的〃'盒〃系統(tǒng)各自存在、各自為政的自治系統(tǒng)的狀況無法再維持下去了，商業(yè)管理需要整合各個系統(tǒng)的信息，實現(xiàn)跨越所有系統(tǒng)的整合管理，同時將企業(yè)內(nèi)的管理信息流與企業(yè)外的管理信息流相結(jié)合以實現(xiàn)高反應(yīng)效率的企業(yè)間的電子商務(wù)。這一需求就需要由EAI和B2Bi的技術(shù)來實施并滿足。GeneralBusiness的IT部門已經(jīng)決定使用WebServices技術(shù)架構(gòu)作為其整個企業(yè)集團內(nèi)部進行EAI和B2Bi的基礎(chǔ)框架技術(shù)。然而，在設(shè)計實施的時候，他們發(fā)現(xiàn)，盡管WebServices技術(shù)在實現(xiàn)不同系統(tǒng)不同平臺之間的對接方面能夠大大簡化代碼，但是，每個應(yīng)用系統(tǒng)都有其自身的用戶系統(tǒng)和認證方式，程序員在為某個應(yīng)用系統(tǒng)編寫接入其它應(yīng)用系統(tǒng)的程序代碼的時候，常常為了用戶認證大傷腦筋：1)讓最終用戶頻繁登錄？似乎是一個讓用戶很難接受的解決方案。2)在代碼中內(nèi)置用戶名和密碼？代碼需要隨用戶和密碼的變化經(jīng)常維護，同時在很多場合下，用戶名和密碼對于程序員來說可能是不可見的。如何解決這一問題呢？經(jīng)過討論，GeneralBusiness決定開發(fā)一個統(tǒng)一身份認證服務(wù)，以解決這一應(yīng)用集成中碰到的用戶認證的問題。這個服務(wù)需要達到以下功能和目標：支持WebServices技術(shù)框架，使得在對各個應(yīng)用系統(tǒng)實施基于WebServices的應(yīng)用集成(EAI/B2Bi)的時候能夠使用這個統(tǒng)一身份認證服務(wù)進行身份認證。方便使用，能夠盡可能地利用現(xiàn)有系統(tǒng)的身份認證模塊以及現(xiàn)有的用戶設(shè)置和權(quán)限設(shè)置，盡量保護現(xiàn)有的投資，減少重新的用戶設(shè)置和權(quán)限設(shè)置的費用，同時避免對現(xiàn)有系統(tǒng)進行大規(guī)模的修改。具有良好的擴展性和可集成性，不僅能支持現(xiàn)有的應(yīng)用系統(tǒng)及其現(xiàn)有的用戶系統(tǒng)，當有新的企業(yè)應(yīng)用被部署或開發(fā)的時候，這個統(tǒng)一身份認證服務(wù)可以作為它的身份認證模塊的形式工作，也就是說，新的企業(yè)應(yīng)用可以不自帶用戶系統(tǒng)，可以通過集成該服務(wù)的形式來實現(xiàn)等價的功能。應(yīng)當具備靈活和方便的使用模式，使用者可以通過多種方式自由地使用該統(tǒng)一身份認證服務(wù)。回頁首解決方案根據(jù)這個統(tǒng)一身份認證服務(wù)的目標和初步的功能定義，我們將這個服務(wù)設(shè)計如下:

用戶注冊：用戶在統(tǒng)一身份認證服務(wù)中注冊帳號，以后這個帳號可以在所有使用統(tǒng)一身份認證服務(wù)的應(yīng)用系統(tǒng)中使用。帳號關(guān)聯(lián)：如果用戶之前已經(jīng)在相關(guān)的應(yīng)用系統(tǒng)中擁有帳號，同時也已經(jīng)設(shè)置了相應(yīng)的權(quán)限，那么用戶能夠?qū)⑦@些應(yīng)用系統(tǒng)的帳號與統(tǒng)一身份認證服務(wù)的帳號進行關(guān)聯(lián)，使得用戶登錄統(tǒng)一身份認證服務(wù)之后，就能夠自動使用相關(guān)的應(yīng)用系統(tǒng)用戶來訪問應(yīng)用系統(tǒng)。用戶認證：為應(yīng)用系統(tǒng)提供用戶身份認證，兼顧兩個應(yīng)用方式：4.o應(yīng)用系統(tǒng)使用統(tǒng)一身份認證服務(wù)作為它的用戶系統(tǒng)，用戶與應(yīng)用系統(tǒng)進行交互，進行登錄操作，應(yīng)用系統(tǒng)將用戶提供的用戶名/密碼等轉(zhuǎn)發(fā)給統(tǒng)一身份認證服務(wù)以檢驗其是否通過授權(quán)。o用戶首先登錄統(tǒng)一身份認證服務(wù)，并獲取權(quán)限令牌，以后可以使用這個權(quán)限令牌訪問其他的應(yīng)用系統(tǒng)，應(yīng)用系統(tǒng)接收該權(quán)限令牌時應(yīng)當與統(tǒng)一身份認證服務(wù)進行交互，以檢驗訪問的合法性。按照以上的功能描述，我們可以認為統(tǒng)一身份認證服務(wù)中需要考慮的實體可以使用下圖來表示：

用戶(User):即統(tǒng)一身份認證服務(wù)的用戶；帳號(Account)：應(yīng)用系統(tǒng)的帳號，與統(tǒng)一身份認證服務(wù)的用戶相關(guān)聯(lián)，一個用戶可以關(guān)聯(lián)多個帳號；應(yīng)用系統(tǒng)(Application)：使用統(tǒng)一身份認證服務(wù)的應(yīng)用系統(tǒng)；會話(Session)：當用戶登錄統(tǒng)一身份認證服務(wù)后，即創(chuàng)建了一個活躍的會話，并獲得會話的認證令牌，在這個會話中，用戶可以使用會話的認證令牌訪問各種應(yīng)用系統(tǒng)。用戶注冊用戶注冊(包括用戶更新注冊信息)的流程可以使用下圖來表示。其中主要包含了兩個流程：新用戶注冊和用戶更新注冊信息。Figure3.用戶注冊流程新用戶注冊：用戶向統(tǒng)一身份認證服務(wù)發(fā)出新用戶注冊請求服務(wù)查詢用戶注冊庫，如果該用戶可以注冊（沒有同名ID等違背約束條件的情況發(fā)生），那么將該用戶的信息保存到用戶注冊庫中。當保存完畢后，統(tǒng)一身份認證服務(wù)響應(yīng)用戶，注冊完成。用戶更新注冊信息：用戶向統(tǒng)一身份認證服務(wù)發(fā)出用戶注冊信息更新請求。服務(wù)查詢用戶注冊庫，如果該用戶信息可以更新（有該ID存在，同時提供的密碼也是正確的等等），那么將該用戶的信息將在用戶注冊庫中更新。當保存完畢后，統(tǒng)一身份認證服務(wù)響應(yīng)用戶，更新完成。帳號關(guān)聯(lián)帳號關(guān)聯(lián)操作可以使用下圖來表示。圖中僅包含一個登記新的帳號關(guān)聯(lián)的操作，相關(guān)的修改、刪除操作被省略了，有興趣的讀者可以自行給出。

登記新的帳號關(guān)聯(lián):用戶向統(tǒng)一身份認證服務(wù)發(fā)出帳號關(guān)聯(lián)注冊請求，用戶提供了應(yīng)用系統(tǒng)的標識A，同時提供了可以在該應(yīng)用系統(tǒng)中使用的用戶信息（可能包含用戶名和密碼等）。服務(wù)首先向該應(yīng)用系統(tǒng)A征詢，用戶信息是否合法。如果合法則響應(yīng)服務(wù)。如果收到合法響應(yīng)，那么服務(wù)就將這個帳號關(guān)聯(lián)注冊信息保存到用戶注冊庫中，以后該用戶登錄統(tǒng)一身份認證服務(wù)之后，就能夠使用相應(yīng)的應(yīng)用系統(tǒng)A。當注冊庫完成保存操作后，統(tǒng)一身份認證服務(wù)響應(yīng)用戶，注冊完成。身份認證組件模式統(tǒng)一身份認證服務(wù)的一個基本應(yīng)用模式是以應(yīng)用系統(tǒng)的身份認證組件的形式工作，在這個應(yīng)用模式下，主導(dǎo)地位的是應(yīng)用系統(tǒng)。在這種情況下，應(yīng)用系統(tǒng)自身沒有用戶系統(tǒng)，因此本模式下涉及的帳號一定是統(tǒng)一身份認證服務(wù)的用戶帳號。Figure5.身份認證組件模式流程Figure5.身份認證組件模式流程流程描述如下：（僅描述正常流程）用戶使用在統(tǒng)一認證服務(wù)注冊的用戶名和密碼（也可能是其他的授權(quán)信息，比如數(shù)字簽名等）登陸應(yīng)用系統(tǒng)A應(yīng)用系統(tǒng)A，將用戶名和密碼連同自己的標識（應(yīng)用系統(tǒng)A的標識）一起轉(zhuǎn)發(fā)給統(tǒng)一認證服務(wù)，要求統(tǒng)一認證服務(wù)完成登錄操作。統(tǒng)一認證服務(wù)核查自己的應(yīng)用系統(tǒng)注冊庫（使用UDDIRegistry，我將在后面解釋為什么使用UDDIRegistry）看看應(yīng)用系統(tǒng)A是否已經(jīng)是統(tǒng)一認證服務(wù)的用戶系統(tǒng)。同時在用戶注冊庫中核查由應(yīng)用系統(tǒng)A轉(zhuǎn)發(fā)過來的用戶名和密碼。待核查完畢后，統(tǒng)一認證服務(wù)響應(yīng)應(yīng)用系統(tǒng)A，登錄完成。應(yīng)用系統(tǒng)A創(chuàng)建一個系統(tǒng)會話（Session，系統(tǒng)A自己的機制），并將應(yīng)用系統(tǒng)A自己的權(quán)限令牌返回給用戶，以后用戶端可以通過這個權(quán)限令牌持續(xù)訪問應(yīng)用系統(tǒng)A，直至登出系統(tǒng)或是會話超時。統(tǒng)一認證模式統(tǒng)一認證模式是以統(tǒng)一身份認證服務(wù)為核心的服務(wù)使用模式。用戶登錄統(tǒng)一身份認證服務(wù)后，即可使用所有支持統(tǒng)一身份認證服務(wù)的應(yīng)用系統(tǒng)。流程描述如下：（僅描述正常流程）用戶使用在統(tǒng)一認證服務(wù)注冊的用戶名和密碼（也可能是其他的授權(quán)信息，比如數(shù)字簽名等）登陸統(tǒng)一認證服務(wù)；統(tǒng)一認證服務(wù)創(chuàng)建了一個會話，同時將與該會話關(guān)聯(lián)的訪問認證令牌返回給用戶；用戶使用這個訪問認證令牌訪問某個支持統(tǒng)一身份認證服務(wù)的應(yīng)用系統(tǒng)；該應(yīng)用系統(tǒng)將訪問認證令牌傳入統(tǒng)一身份認證服務(wù)，認證訪問認證令牌的有效性；統(tǒng)一身份認證服務(wù)確認認證令牌的有效性；應(yīng)用系統(tǒng)接收訪問，并返回訪問結(jié)果，如果需要提高訪問效率的話，應(yīng)用系統(tǒng)可選擇返回其自身的認證令牌已使得用戶之后可以使用這個私有令牌持續(xù)訪問。此外，關(guān)于訪問認證令牌的失效，有兩個策略，一個是由用戶主動發(fā)起聲明，聲明其擁有的訪問認證令牌不再有效，這類似注銷的操作，另一個是用戶一段時間內(nèi)沒有使用這個認證令牌，認證令牌自動失效，這類似超時的處理。信任代理模式在Internet應(yīng)用環(huán)境下，安全性和信任的重要性是顯而易見的，對于商用系統(tǒng)而言，避免非法訪問和入侵是他所需要考慮的幾個重要問題之一，沒有比商用數(shù)據(jù)丟失或是商用系統(tǒng)被違規(guī)使用更糟糕的了。在信任代理模式下，一個組織可以為他所有需要提供安全信任保障的應(yīng)用系統(tǒng)設(shè)置一個統(tǒng)一身份認證服務(wù)，對這些應(yīng)用系統(tǒng)的訪問全部由統(tǒng)一身份認證服務(wù)代理。流程描述如下：（僅描述正常流程）用戶使用在統(tǒng)一認證服務(wù)注冊的用戶名和密碼（也可能是其他的授權(quán)信息，比如數(shù)字簽名等）登陸統(tǒng)一認證服務(wù)；統(tǒng)一認證服務(wù)創(chuàng)建了一個會話，同時將與該會話關(guān)聯(lián)的訪問認證令牌返回給用戶；用戶使用這個訪問認證令牌訪問某個支持統(tǒng)一身份認證服務(wù)的應(yīng)用系統(tǒng)，不過用戶并不將請求消息直接交給應(yīng)用系統(tǒng)，而是傳給統(tǒng)一身份認證服務(wù)，在消息中標識了最終的應(yīng)用系統(tǒng)的ID。統(tǒng)一認證服務(wù)訪問應(yīng)用系統(tǒng)注冊庫（UDDIRegistry），獲取了應(yīng)用系統(tǒng)的訪問入口（統(tǒng)一認證服務(wù)可以將這個訪問入口緩存在本地，以減少以后與應(yīng)用系統(tǒng)注冊庫的交互次數(shù)）。并確認這個應(yīng)用系統(tǒng)的確是支持統(tǒng)一身份認證服務(wù)的；統(tǒng)一認證服務(wù)將請求消息轉(zhuǎn)發(fā)給指定的應(yīng)用系統(tǒng)，如果該應(yīng)用系統(tǒng)使用自己的用戶系統(tǒng)的話，那么該消息應(yīng)當包含了預(yù)先定義好的相關(guān)聯(lián)的用戶名和密碼等。應(yīng)用系統(tǒng)將請求結(jié)果返回給統(tǒng)一認證服務(wù)，最后統(tǒng)一認證服務(wù)將響應(yīng)消息返回給用戶，完成調(diào)用。在該模式下，所有應(yīng)用系統(tǒng)僅接收來自統(tǒng)一認證服務(wù)的訪問請求，這樣，解決方案提供商可以將主要的安全方面的投入部署在統(tǒng)一認證服務(wù)那端。回頁首使用Web服務(wù)架構(gòu)由于統(tǒng)一身份認證服務(wù)可能被應(yīng)用的領(lǐng)域包括:企業(yè)內(nèi)部的各種應(yīng)用?跨國企業(yè)的各個部門或地區(qū)分公司的各種應(yīng)用?行業(yè)內(nèi)各個企業(yè)的不同應(yīng)用.Internet上豐富的應(yīng)用環(huán)境無論是何種應(yīng)用環(huán)境，都將面對不同的平臺、不同的系統(tǒng)和不同的編程環(huán)境，要能最大可能地支持所有的平臺、系統(tǒng)和編程環(huán)境，同時又要確保服務(wù)的實現(xiàn)代價保持相對固定，那么目前看來，選擇基于規(guī)范的WebServices解決方案將是一個不錯的選擇。UDDI的角色在我們這個基于統(tǒng)一身份識別服務(wù)的應(yīng)用環(huán)境中，所有支持統(tǒng)一身份識別服務(wù)的應(yīng)用系統(tǒng)都需要被注冊在UDDI注冊中心中。如果是企業(yè)內(nèi)部的應(yīng)用環(huán)境、跨國企業(yè)的應(yīng)用環(huán)境或是行業(yè)內(nèi)多個企業(yè)組成的聯(lián)合行業(yè)應(yīng)用環(huán)境，那么應(yīng)當使用PrivateUDDIRegistry（私有UDDI注冊中心），如果是Internet應(yīng)用環(huán)境的話，則可以考慮使用PublicUDDIRegistry（公共UDDI注冊中心）。所有支持統(tǒng)一身份識別服務(wù)的應(yīng)用系統(tǒng)以UDDI數(shù)據(jù)實體businessService的形式注冊在UDDI注冊中心中，他們都被分配了一個UUID（唯一標識符），這個UUID可以在用戶定義關(guān)聯(lián)帳號或是使用統(tǒng)一身份認證服務(wù)進行應(yīng)用系統(tǒng)訪問的時候，用于標識相應(yīng)的應(yīng)用系統(tǒng)。businessService是UDDI中的一個關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)，businessService將一系列有關(guān)商業(yè)流程或分類目錄的WebService的描述組合到一起。businessService和下面要提到的bindingTemplate一起構(gòu)成了技術(shù)信息。其中，一個可能的商業(yè)流程的例子是一組相關(guān)的Web服務(wù)信息，包括采購服務(wù)、運輸服務(wù)和其它的高層商業(yè)流程。這些服務(wù)都將是提供這些商業(yè)流程服務(wù)的商業(yè)實體所需要注冊的Web服務(wù)。這些businessService的信息集合可以再次加以分類，使Web應(yīng)用服務(wù)的描述可以按不同的行業(yè)、產(chǎn)品、服務(wù)類型或是地域劃分來進行。分類的方法的機制與businessEntity是類似的。對于每一個businessService，存在一個或多個Web服務(wù)的技術(shù)描述bindingTemplate。這些技術(shù)描述包括應(yīng)用程序連接遠程Web服務(wù)并與之通訊所必須的信息。這些信息包括Web應(yīng)用服務(wù)的入口地址、應(yīng)用服務(wù)宿主和調(diào)用服務(wù)前必須調(diào)用的附加應(yīng)用服務(wù)等。另外，通過附加的特性還可以實現(xiàn)一些復(fù)雜的路由選擇，諸如負載平衡等。當統(tǒng)一身份認證服務(wù)得到用戶提交的應(yīng)用系統(tǒng)的UUID之后，它應(yīng)當使用這個UUID查詢UDDI注冊中心，以獲得這個應(yīng)用系統(tǒng)的完整服務(wù)描述（businessService結(jié)構(gòu)），隨后統(tǒng)一身份認證服務(wù)就可以得到這個應(yīng)用系統(tǒng)的訪問入口，并實施訪問。當應(yīng)用系統(tǒng)修改了訪問入口或是某些關(guān)鍵的技術(shù)信息之后，它可以在UDDI注冊中心中更新自己的信息，這樣，當統(tǒng)一身份認證服務(wù)下一次實施關(guān)聯(lián)的查詢時，就可以獲取新的應(yīng)用系統(tǒng)的訪問信息，這樣一種方式可以無需修改代碼實現(xiàn)動態(tài)綁定。為了提高服務(wù)的響應(yīng)效率，減少與UDDI注冊中心的交互次數(shù)，統(tǒng)一身份認證服務(wù)也可以選擇將應(yīng)用系統(tǒng)的UDDI描述緩存在本地，當用戶訪問相關(guān)的應(yīng)用系統(tǒng)時可以直接使用緩存的數(shù)據(jù)進行后繼操作。細心的讀者應(yīng)當已經(jīng)發(fā)現(xiàn)，緩存操作與前面描述的應(yīng)用系統(tǒng)自更新技術(shù)信息的操作可能會發(fā)生沖突，緩存的信息與UDDI中的信息可能發(fā)生版本不一致的情況，此時后繼的應(yīng)用系統(tǒng)訪問操作可能會發(fā)生錯誤，當這種錯誤發(fā)生后，統(tǒng)一身份認證服務(wù)應(yīng)當選擇重新緩存相關(guān)的UDDI中的應(yīng)用系統(tǒng)技術(shù)信息以恢復(fù)數(shù)據(jù)的一致性。Web服務(wù)接口根據(jù)前面幾個部分的描述，我們可以歸納出統(tǒng)一身份認證服務(wù)的對外接口，接口基本上由兩部分組成：用戶Profile維護：包括用戶注冊，關(guān)聯(lián)帳號定義，帳號信息維護等。認證服務(wù)：包括用戶登錄/注銷，認證令牌認證，訪問轉(zhuǎn)發(fā)，訪問代理等用戶Profile維護用戶Profile維護的XMLSchema定義如下:<?xmlversion=〃1.0"encoding=〃UTF-8〃？><xs:schemaxmlns:xs="/2001/XMLSchema”elementFormDefault="qualified"attributeFormDefault="unqualified”〉<xs:elementname="user"type="userType"><xs:annotation><xs:documentation>USASUserDefinition</xs:documentation></xs:annotation></xs:element><xs:complexTypename="userType"><xs:sequence><xs:elementname="userID"type="emailType"/><xs:elementname="credential"type="xs:base64Binary"/><xs:elementname="personalInfo"><xs:complexType><xs:sequence><xs:elementname="name"type="xs:string"/><xs:elementname="alternativeEmail"type="emailType"/><xs:elementname="phone"type="xs:string"/><xs:elementname="fax"type="xs:string"/><xs:elementname="company"type=〃xs:string〃/><xs:elementname="department"type="xs:string"/></xs:sequence></xs:complexType></xs:element><xs:elementname="associatedAccounts"><xs:complexType><xs:sequence><xs:elementname="associatedAccount"type="accountType"minOccurs="0"maxOccurs="unbounded"/〉</xs:sequence></xs:complexType></xs:element></xs:sequence></xs:complexType><xs:simpleTypename="emailType"><xs:restrictionbase="xs:string"/></xs:simpleType><xs:complexTypename="accountType"><xs:sequence><xs:elementname="applicationID"type="xs:string"/><xs:elementname="accountID"type="xs:string"/><xs:elementname="credential"type="xs:base64Binary"/></xs:sequence></xs:complexType><xs:elementname="save_user"><xs:complexType><xs:sequence><xs:elementref="user"/></xs:sequence></xs:complexType></xs:element><xs:elementname="delete_user"><xs:complexType><xs:sequence><xs:elementname="userID"type="emailType"/><xs:elementname="credential"type="xs:base64Binary"/></xs:sequence></xs:complexType></xs:element></xs:schema>從這個XMLSchema文檔中，我們不難看出，我們可以使用兩個API來維護用戶帳號：save_user和delete_user。其中save_user用于新建帳號和更新帳號。當統(tǒng)一身份認證服務(wù)接受到save_userAPI調(diào)用時，如果發(fā)現(xiàn)服務(wù)的用戶庫中并沒有相應(yīng)的userID，那么就是新建帳號，否則如果發(fā)現(xiàn)服務(wù)的用戶庫中有相應(yīng)的userID，那么就是更新帳號。而delete_user則用于刪除帳號，當然前提是服務(wù)的用戶庫中有相應(yīng)的userID，否則就是非法調(diào)用。在delete_userAPI調(diào)用中，頂級元素是delete_user，delete_user有兩個子元素userID和credential，userID是用戶的標識，其類型是email地址，使用email地址作為用戶標識也是目前非專用用戶系統(tǒng)比較通用的一種方式，原因非常簡單，email地址不同的人肯定不會重復(fù)，這樣就避免了帳號無法成功注冊的情況。而credential則是對應(yīng)的授權(quán)信息，可能是用戶密碼，數(shù)字簽名等等形式。對于save_userAPI調(diào)用而言，其頂級元素是save_user，而save_user有一個子元素user，user元素完整定義了一個用戶帳號的詳細信息。除了userID和credential子元素外，user元素還包括兩個復(fù)合元素personalInfo和associatedAccounts°personalInfo元素描述了用戶的個人信息，包括:name（姓名）、alternativeEmail（可替換的email，userID是其使用的主要email）、phone（電話）、fax（傳真）、company（所屬公司）、department（所屬部門）。而associatedAccounts則定義了多個關(guān)聯(lián)帳號，每個關(guān)聯(lián)帳號的定義（associatedAccount）由三個元素組成：applicationID（應(yīng)用系統(tǒng)的UDDIUUID標識）、accountID（應(yīng)用系統(tǒng)中的用戶ID）、credential（應(yīng)用系統(tǒng)中相關(guān)用戶ID對應(yīng)的授權(quán)信息，可能是密碼、數(shù)字簽名等）。認證服務(wù)認證服務(wù)API主要包含sign_in、check_authToken、discard_authToken等API調(diào)用。sign_in消息用于登錄統(tǒng)一身份認證服務(wù)，并獲得認證令牌。認證令牌是登錄之后訪問統(tǒng)一身份認證服務(wù)以及使用應(yīng)用系統(tǒng)所必須的不可缺少的必要參數(shù)。sign_inAPI調(diào)用的消息語法形如：<sign_in><userID>"someLoginName"</userID><credential>"someCredential"</credential></sign_in>其中userID是用戶的標識，其類型是email地址，使用email地址作為用戶標識也是目前非專用用戶系統(tǒng)比較通用的一種方式，原因非常簡單，email地址不同的人肯定不會重復(fù)，這樣就避免了帳號無法成功注冊的情況。而credential則是對應(yīng)的授權(quán)信息，可能是用戶密碼，數(shù)字簽名等等形式。當sign_in成功調(diào)用后，統(tǒng)一身份認證服務(wù)需要返回認證令牌以供此后的授權(quán)訪問。authToken消息是sign_in消息的響應(yīng)消息。它返回認證信息authInfo，認證信息將用于后續(xù)的調(diào)用。authToken消息的語法形如：<authToken><authInfo>someopaquetokenvalue</authInfo></authToken>authToken消息包含單個authInfo元素，該元素包含一個訪問令牌，令牌將在所有后繼API消息調(diào)用中被使用。作為一個對sign_in消息的同步響應(yīng)，這個消息返回時始終使用SSL加密。當應(yīng)用系統(tǒng)收到用戶傳來的認證令牌后，可以選擇到統(tǒng)一身份認證服務(wù)驗證該認證令牌的合法性，并依據(jù)結(jié)果判斷是否接受用戶的訪問請求。這個驗證認證令牌的API函數(shù)是check_authToken。check_authToken消息的語法形如：<check_authToken><authInfo>someopaquetokenvalue</authInfo></check_authToken>當認證令牌合法，將返回valid，如果認證令牌不合法或者已經(jīng)失效，則返回invalid。當用戶完成了它所需的各種操作，那么它應(yīng)當從統(tǒng)一身份認證服務(wù)中注銷，以避免獲取的認證令牌被非法濫用。此時它可以使用discard_authToken函數(shù)。discard_authTokenAPI調(diào)用用來通知統(tǒng)一身份認證服務(wù)可以丟棄某個認證令牌，也就是終止當前的會話。以后一切使用該認證令牌的調(diào)用全部會被拒絕。discard_authToken的語法形如：<discard_authToken><authInfo/></discard_authToken>查詢UDDI注冊中心我們先前已經(jīng)提到，統(tǒng)一身份認證服務(wù)在得到用戶傳入的應(yīng)用系統(tǒng)UUID之后，需要去查詢UDDI注冊中心以獲得相關(guān)應(yīng)用系統(tǒng)的技術(shù)信息以被之后的服務(wù)調(diào)用。這個查詢API具體來說，就是get_serviceDetail函數(shù)。get_serviceDetail消息用來請求獲取已知的businessService結(jié)構(gòu)的完整信息。語法形如：<get_serviceDetailgeneric=”2.0"xmlns="urn:uddi-org:api_v2"><serviceKey/>[<serviceKey/>...]</get_serviceDetail>其中serviceKey用于表示一個或多個用來代表已知businessService數(shù)據(jù)特定實例的uuid_key值。該函數(shù)若成功調(diào)用，則返回一個serviceDetail消息，其成功匹配了一個或多個serviceKey值。如果傳入的是多個serviceKey值，其結(jié)果將根據(jù)傳入的值的次序依次返回。如果匹配到的記錄數(shù)量過多，操作入口站點將對返回值執(zhí)行截斷操作。如果該情況發(fā)生，serviceDetail將包含一個truncated屬性，且該屬性值為true。serviceDetail消息返回一個或多個完整的businessService結(jié)構(gòu)，作為對get_serviceDetail查詢消息的響應(yīng)。語法形如:〈serviceDetailgeneric=”2.0"operator=”uddi.sourceOperator”[truncated="false"]xmlns="urn:uddi-org:api_v2"><businessServicebusinessKey="urn:uuid_key”serviceKey="urn:uuid_key">...</businessService>[<businessService/>...]</serviceDetail>需要注意的是，businessKey值在該消息中被表述，這是因為子元素的父容器（serviceDetail元素）并不提供到父businessEntity結(jié)構(gòu)的鍵引用。其中businessService用于表示一個或多個的完整的在UDDI注冊中心中的businessService結(jié)構(gòu)。這些結(jié)構(gòu)是由get_serviceDetail消息所指定的。信任代理模式示例通過之前的闡述，相信大家對于身份認證組建模式和統(tǒng)一認證模式的實現(xiàn)已經(jīng)沒有過多的疑問了。在本節(jié)，我將結(jié)合之前描述的體系和API設(shè)計，針對信任代理模式，通過一個具體的例子演示統(tǒng)一身份認證服務(wù)的使用方法。這個例子的應(yīng)用場景是一個生產(chǎn)和銷售電子器件的企業(yè)，它使用了ERP系統(tǒng)管理其自身的生產(chǎn)流程和庫存、使用SCM系統(tǒng)管理與供應(yīng)商之間的供應(yīng)流程，同時使用CRM系統(tǒng)管理客戶、分銷等。在最初，各個系統(tǒng)分別使用自己的用戶系統(tǒng)，公司員工在使用這三個系統(tǒng)，并在三個系統(tǒng)之間切換的時候非常煩惱，不得記住三套用戶并多次重復(fù)登錄，工作效率也有所影響。隨著更多的企業(yè)應(yīng)用被一一部署，企業(yè)IT部門認為如果能夠?qū)⒂脩粝到y(tǒng)統(tǒng)一的話，將會顯著地提高員工的工作效率。同時企業(yè)IT部分選定了信任代理模式來實施統(tǒng)一身份認證服務(wù)。這樣所有的授權(quán)訪問能夠置于統(tǒng)一身份認證服務(wù)的監(jiān)控之下，便于企業(yè)管理部門對訪問的監(jiān)控和審計。下面我用使用SOAP消息的形式來演示用戶訪問SCM系統(tǒng)的流程。用戶使用在統(tǒng)一認證服務(wù)注冊的用戶名和密碼登陸統(tǒng)一認證服務(wù)，用戶名是"UATest"，而密碼則使用了Base64編碼表示的HASH值；<env:Envelopexmlns:env="/2001/12/soap-envelope"><env:Header><ac:universalauthenticationxmlns:ac="/universalauthentication"><sign_in><userID>UATest</userID><credential>EH67ij45DGg5</credential></sign_in></ac:universalauthentication></env:Header><env:Body></env:Body></env:Envelope>統(tǒng)一認證服務(wù)創(chuàng)建了一個會話，同時將與該會話關(guān)聯(lián)的訪問認證令牌返回給用戶，在SOAP消息中，訪問認證令牌使用Base64編碼；<env:Envelopexmlns:env="/2001/12/soap-envelope"><env:Header><ac:universalauthenticationxmlns:ac="/universalauthentication"><authToken><authI