共用方式為

Web 服務世界中的身分識別同盟

  • 發行項

著作權聲明

 

© 2001-2003 International Business Machines Corporation， Microsoft Corporation. 著作權所有，並保留一切權利。

摘要

本檔說明同盟身分識別管理的問題，並根據WS-Security藍圖和其他相關 Web 服務規格中所述的 Web 服務規格來描述完整的解決方案。

本白皮書中所述的方法，將在WS-Federation規格中進一步定義，引進身分識別提供者作為安全性權杖服務的類別。 因此，它會使用WS-Trust和WS-Federation的機制，在同盟內和跨同盟建立和代理信任。 此外，系統會定義單一登入和登出的機制、根據授權和隱私權原則共用屬性，以及在不同網站/同盟) 使用之假名的整合處理 (別名。

本文中所識別的規格一起提供一組完整且整合的通訊協定，藉由與其他安全性和 Web 服務規格組合，在同盟之間提供安全的可靠交易訊息。

執行摘要

在過去數年，Web 應用程式從簡單的內容傳遞應用程式演進到複雜的商務生產力工具，以及跨企業的應用程式整合的機制。 Web 和 Web 服務的成長已示範許多技術問題的開放且互通的解決方案需求。

在本檔中，我們將焦點放在一組特定的安全性相關問題。 其中包括：

如何判斷正確的安全身分識別和位置 Web 服務：組織需要一種標準的方式，讓服務要求者 (客戶和合作夥伴) 安全地尋找指定業務的正確 Web 服務，以及讓商務服務提供者 安全地 識別並公開正確的 Web 服務給只有授權的要求者。

如何判斷一組認證，以啟用 Web 服務的安全調用：一種標準化的方法，可供商務服務要求者使用正確的驗證、授權和權利集安全地叫用 Web 服務。

如何安全地建立 Web 服務同盟：允許企業直接為在其他 (合作夥伴) 企業或機構註冊的客戶提供服務的標準方式。 在服務同盟內，企業可以從使用者的主組織取得使用者的信任資訊， (或資訊提供服務) 。 企業不需要註冊和維護該使用者的身分識別，而且使用者不需要取得並記住新的登入，才能與企業互動。

如何啟用跨企業和跨網域信任：建立及反映組織間信任的標準方式。 這是同盟服務的重要問題。

如何啟用同盟身分識別和屬性對應：瞭解良好的機制和程式，可對應外部使用者 (信任的資訊，例如，來自企業合作夥伴的使用者) 驗證和授權資訊可供企業現有的服務使用。

如何啟用安全、可靠交易：在安全、可靠且交易的內容中交換訊息的標準方式。 先前的規格 (例如WS-ReliableMessaging和 WS-Transaction) 可支援可靠的訊息交換和商務交易。 在本檔中，我們將討論同盟安全性支援。

IBM、Microsoft 和我們的合作夥伴想要與客戶、合作夥伴和標準機構合作，以發展這裡所述的規格，並確保這些規格與 Web 服務架構的其他元素一起撰寫良好。 為了確保本文中所述各種建議規格的互通性和一致實作，IBM、Microsoft 和我們的合作夥伴將會與標準組織、開發人員社群，以及 WS-I.org 等產業組織密切合作，以開發互通性設定檔和測試，以提供工具廠商指引。

由於術語在技術之間有所不同，因此本檔會定義數個詞彙，這些詞彙可能會一致地套用到不同的安全性格式和機制。 因此，此處使用的術語可能與其他規格不同，而且已定義，讓讀者可以將詞彙對應至其慣用詞彙。 若要了解 這些詞彙及其定義和使用方式摘要的術語區段。

1 簡介和動機

同盟身分識別管理代表個人和企業的重大挑戰。 本章會探索問題，然後識別受其影響之合作物件，並找出可行解決方案的重要目標。

什麼是同盟身分識別管理問題？

公司的價值網路橫跨許多組織、系統、應用程式和商務程式。 數個不同的組成者組成這個價值網路，包括客戶、員工、合作夥伴、供應商和轉銷商。 沒有任何單一實體或公司可以集中管理或控制此端對端值網路中其組成專案的身分識別資訊。 即使是在單一公司內，也可能有多個授權的身分識別資料來源，這些來源必須在業務單位內獨立且自發地管理。

以跨公司共同作業的基礎原則進行集中化的方法，在電子商務共同作業、整合和自動化方面帶來顯著的衝突，導致身分識別管理和效率降低的高成本。 透過集中化，管理使用者身分識別生命週期的成本很高。 大部分的企業都必須管理員工、商務夥伴和客戶身分識別。 此外，企業與這些個人之間的關聯性會經常變更，而且每個變更都需要系統管理動作。

在某些情況下，企業想要將某些安全性功能外包給管理身分識別 (的合作物件，因為其目前對交易內容中的信用卡公司) ，但基於兩個原因而無法這麼做：首先，沒有協力廠商身分識別提供者提供取用者財務交易以外的市場，而第二，沒有商務和責任模型可安全地依賴服務協力廠商身分識別提供者的服務除了取用者財務交易以外。

其他企業想要利用他們維護的身分識別，以啟用額外的商務互動。 不過，建立信任機制以允許跨業務界限同盟的實體很困難。 此外，如果身分識別管理動作發行或使用與個別隱私權衝突的方式，管理身分識別的企業越來越有信譽損害或法規責任的風險。 這可大幅增加管理身分識別的風險。

從個人的觀點來看，有多個身分識別，同時存在個人和專業。 個人也有身分識別管理問題，因為無法重複使用身分識別。

同盟身分識別管理提供跨公司商務彈性，同時讓公司能夠卸載負載並簡化身分識別管理成本。 這可讓公司達成最符合其商務模型、IT 原則和安全性與治理目標和需求的商務整合目標。

誰有同盟身分識別管理問題？

主要整合障礙在於跨公司業務整合，因為缺乏安全的通訊模型。 問題會影響各種公司，包括：

  • 使用身分識別資訊的中型和大型組織，將服務提供給取用者 (例如 Web 型旅遊服務的提供者) 。
  • 與彼此合作的中型和大型組織需要交換個人身分識別的相關資訊 (，例如，航空公司和計程車機構，或醫院和醫療保健提供者)
  • 需要跨企業整合商務應用程式和供應商價值鏈結的組織 (例如供應鏈) ，而且必須授權員工代表組織進行交易。
  • 例如，將人力資源和權益等服務外包給協力廠商，但將自己的品牌套用至這些外包服務的組織 (，組織會透過自己的內部 HR 入口網站提供多個淘汰方案或醫療方案選項) ，因此必須與服務提供者共用員工身分識別資訊。
  • 組織 (中繼人、訊息代理程式、匯總工具) ，其商務模型是由「擁有客戶體驗」所驅動，原因為解除媒體。
  • 提供整合式品牌完整服務身分識別驅動商務入口網站的組織， (金融服務、保險服務、訂用帳戶等) ，方法是跨多個協力廠商提供者匯總服務。

如先前所述，參與網頁式活動的個人也會遇到此問題，因為其通常具有大量獨立身分識別，這些識別必須建立和管理。

目標

同盟身分識別服務的主要目標如下：

  • 藉由減少重複工作來降低身分識別管理的成本;每個個人的身分識別幾乎一律由信任的組織管理 (，例如個人銀行、雇主或醫生) 。
  • 利用這些現有身分識別管理員已完成的工作，方法是視需要提供其他合作物件存取權 (，以及適當的隱私權保護) 相關的身分識別資訊。
  • 保留所有合作物件的自主性 - 身分識別管理員選擇的驗證技術不應對依賴其身分識別資訊之合作物件強制執行該技術。 身分識別管理員選擇作業系統或網路通訊協定或資料庫，不應對其合作夥伴施加相同的選擇。
  • 遵守企業預先存在的信任結構和合約。 註冊以接收身分識別提供者的身分識別資訊，不得要求組織與識別提供者以外的任何合作物件建立信任關係，而且不得採用任何特定的使用者驗證技術。
  • 遵守並強制執行使用者喜好設定，以保護個人的隱私權，以控管個別識別資訊的使用、觀察政府與地區隱私權規則、尋求使用者對新用途的同意，以及實作強式記錄記錄和責任機制，以確保遵循隱私權做法。
  • 建置開放標準，為企業和個人啟用安全的可靠交易。

2.同盟單一登入和身分識別管理

同盟的吸引力在於，其旨在允許使用者順暢地周遊指定同盟內的不同網站。 本檔特別著重于同盟身分識別管理的問題，而不是除了安全性) 以外，一般同盟 (更大的問題。 由於同盟參與者之間建立的信任關係，因此一個參與者能夠驗證使用者，然後作為該使用者的 發行者 。 其他同盟參與者會成為 信賴憑證者。 也就是說，他們依賴發行者提供有關使用者的資訊，而不需要直接介入使用者。 在某些情況下，使用者可能會匿名給信賴憑證者，例如，因為不同的驗證機制和使用協力廠商驗證機制。

Web 服務模型的彈性和吸引力是其建置組塊基礎，讓公司可以輕鬆地建置新的服務來提供創新的商務模型，或透過與合作夥伴、供應商、客戶和員工緊密的關聯性，更有效率地連結其價值鏈結網路。 只有當這類模型可讓客戶、合作夥伴和終端使用者輕鬆地在支援這些服務的網站之間流覽，而不需要持續向各種網站驗證或識別自己，或重複地維護商務同盟內每個成員的個人資訊時，才能成功。

不幸的是，驗證使用者並取得使用者屬性資訊的目前配置 (例如信用卡資訊) 通常會強制使用者向每個感興趣的企業註冊，並經常要求使用者以使用者名稱和密碼) 來識別及驗證 (自己，並強制企業管理不受公司控制的大型且快速變更身分識別基底。 這種模型對於採用 Web 服務有很大的障礙，而且對於使用者和企業而言都是很麻煩的。

普遍模型的另一個缺點是，指定的企業可能會對商務夥伴「提供」其客戶資訊的「提供」部分，而希望改為維護及控制客戶關係。

同盟提供簡單的彈性機制，可識別及驗證合作夥伴組織的使用者，並讓他們能夠順暢地存取該信任同盟內的網站，而不需要使用密碼重新驗證。 此外，同盟標準也會處理提供信任屬性 (例如 X509 憑證、X509v3 屬性憑證、Kerberos 權杖、SAML 判斷提示) 有關 (使用者的問題，例如，包括角色和群組資訊，) 允許隱私權和商務特定規則。

您可以使用簡單的範例來說明同盟單一登入和身分識別的概念：

User John Doe 適用于名為 Pharma456.com 的藥物公司;John 具有具有 Pharma456.com 的帳戶，且必須進行驗證，才能 Pharma456.com 存取其資源。 身為員工，John 擁有公司的特定權益，例如合作夥伴公司的帳戶和服務。 在此範例中，公司的節省服務是由名為 RetireAccounts.com (服務提供者) 的金融服務公司所管理，而投資服務是由服務提供者 InvestAccounts.com () 所管理。 若要存取合作夥伴的資源，例如 RetireAccounts.com 所裝載的儲存入口網站，使用者必須驗證才能 RetireAccounts.com。 RetireAccounts.com 的驗證要求使用者提供其社會安全號碼 (SSN) 、員工識別碼 (由雇主核發的唯一識別碼，在此案例中為 Pharma456.com) ，以及 RetireAccounts.com) 特定的個人 PIN (號碼。

如果沒有同盟，John Doe 必須明確地向 RetireAccounts.com 網站進行驗證，才能存取其節省帳戶，即使他已向 Pharma456.com 進行驗證，而且已透過 Pharma456.com 員工入口網站存取 RetireAcounts.com Web 服務。

不過，使用同盟單一登入 John Doe 可以登入其員工入口網站，按一下入口網站連結，從合作夥伴網站存取其儲存帳戶資訊 (RetireAccounts.com) ，而不需要在合作夥伴網站上重新驗證或提供其他資訊。

同盟也可確保跨公司相同使用者的不同身分識別可以使用同盟管理技術，安全地在兩家公司之間連結。 同盟參與者可以交換身分識別資訊，讓信賴憑證公司可以獨立驗證其網域中的使用者身分識別。

在發行網域 (Pharma456.com) 與信賴憑證網域之間的同盟單一登入 (同盟服務提供者 RetireAccounts.com) 可協助安全且信任的使用者識別碼傳輸，以及其他屬性相關資訊 (，例如授權角色和群組成員資格，以及 EmployeeID、SSN 和 PIN 等使用者權利 #) 。 同盟身分識別管理會定義信賴憑證者 (RetireAccounts.com) 能夠 (根據從發行者收到的受信任) 資訊，判斷使用者的本機有效識別碼。 傳輸的詳細資料可能牽涉到企業與使用者原始企業之間的多個訊息 (和訊息到輔助服務) ，但這些訊息會以透明方式處理給使用者。

為了啟用同盟，我們引進了如上圖所示的識別提供者、屬性服務和假名服務。

識別提供者，例如位於 Pharma456.com、InvestAccounts.com 和 RetireAccounts.com 的識別提供者，提供用於本機對應/編制索引的身分識別 (例如帳戶資訊) 。 藉由使用信任和同盟機制以及信任原則，這些身分識別可讓同盟自動共用和對應身分識別。

屬性服務提供一種方式來同盟存取同盟身分識別的授權屬性。 在上述範例中，當 John Doe 造訪每個合作夥伴的入口網站時，入口網站服務可能會存取 John 的屬性， (獲得授權) 的屬性，以取得必要的資訊並個人化體驗。 為了確保隱私權，John Doe 可完全控制哪些屬性已獲授權給哪些服務。 您可以監視和記錄這些屬性存取，以確保符合與 Pharma456.com 員工建立的已陳述隱私權原則。 我們不會要求特定類型的屬性服務，而是允許使用不同的服務，例如 UDDI。

信任機制提供一種方式，讓信賴憑證者將信任層級與授權單位或身分識別產生關聯，並用於本機對應。 不過，在某些情況下，隱私權考慮希望此對應與目標服務不透明。 也就是說，目標一致知道它是以 John 當地角色為基礎的「John Doe」，但不知道或知道全域身分識別。 假名服務提供對應機制，可用來促進跨同盟的受信任身分識別對應，以保護隱私權和身分識別。

同盟身分識別管理 (包括同盟單一登入) ，是比 Web 單一登入 解決方案更廣泛的概念。 雖然此範例強調 B2C 案例的使用案例，其中 Web SSO 是一項重要功能，但 Federated 單一登入 是更廣泛的概念，可讓企業建置安全 B2B 和 B2C 電子商務的完整架構。

3.同盟身分識別模型

同盟身分識別模型是以 Web 服務基礎結構和安全性規格為基礎，並加以整合，以形成一致且可延伸的安全性模型。 同盟模型會擴充WS-Trust模型，以描述身分識別提供者如何作為安全性權杖服務，以及如何將屬性和假名整合到權杖發行機制中，以提供同盟身分識別對應機制。

總而言之，主體登入和登出識別提供者 (或安全性權杖服務) 。 這可以透過明確訊息或隱含方式當做主體要求權杖來完成。 主體會要求資源/服務的權杖，而已發行的權杖可能代表主體的主要身分識別或適用于範圍的一些假名。 識別提供者 (或 STS) 向感興趣的 (和授權) 收件者發出訊息。 主體會向屬性/假名服務註冊，並新增及使用假名和假名。 服務可以使用提供的身分識別來查詢屬性/假名服務 (可能匿名，這表示要求資訊的合作物件具有不透明權杖，而且不知道實際身分識別) 以取得身分識別的授權資訊。

Web 服務安全性規格

本檔中所述的模型和方法會運用 Web 服務世界的安全性白皮書：建議的架構和藍圖中所述的規格。 每個金鑰規格摘要如下：

  • WS-Security說明如何將簽章和加密標頭附加至 SOAP 訊息。 此外，它描述如何將安全性權杖附加至訊息，包括二進位安全性權杖，例如 X.509 憑證和 Kerberos 票證。
  • WS-Policy代表一組規格，描述安全性 (和其他商務) 原則的功能和條件約束 (，例如必要的安全性權杖、支援的加密演算法、隱私權規則) ，以及如何將原則與服務和端點產生關聯。
  • WS-Trust描述信任模型的架構，可讓 Web 服務藉由要求、發行及交換安全性權杖安全地交互操作。
  • WS-Privacy將說明 Web 服務和要求者如何陳述隱私權喜好設定和組織隱私權實務聲明的模型。
  • WS-SecureConversation說明如何管理和驗證合作物件之間的訊息交換，包括安全性內容交換，以及建立和衍生工作階段金鑰。
  • WS-Federation描述如何在異質同盟環境中管理和代理信任關係，包括支援同盟身分識別、共用屬性，以及管理假名。
  • WS-Authorization將說明如何管理授權資料和授權原則。

此外，其他數個主要 Web 服務規格會完成規格的基礎層：

  • WS-Addressing描述如何指定訊息的識別和定址資訊。
  • WS-MetadataExchange說明如何在服務和端點之間交換中繼資料，例如WS-Policy資訊和 WSDL。
  • WS-ReliableMessaging說明如何確保訊息在存在不可靠的網路中可靠傳遞。
  • WS-Transactions和WS-Coordination說明如何在 Web 服務訊息交換中啟用交易作業。

上述規格與互通性設定檔的組合，可讓客戶透過與其他 Web 服務規格組合同盟和安全性規格，輕鬆地建置可互通的安全可靠交易 Web 服務，以在同盟之間整合。

Profiles

本檔描述可用於不同環境的一般模型。 具體而言，此模型可用於由被動要求者組成的環境中，例如網頁瀏覽器或主動要求者，例如 SOAP 要求者。

同盟規格提供一般模型和架構;設定檔描述如何在這些不同的環境中套用模型。 可以指定其他設定檔，以便將模型整合到其他環境。

每個設定檔規格都會定義如何將WS-Federation中的機制完全套用至指定的環境，例如被動或主動要求者。

因此，本文所述的機制 (識別提供者、登入/登出、安全性權杖、屬性、假名。...) 同時適用于被動要求者 (，例如網頁瀏覽器) 和主動要求者 (，例如作為用戶端和服務) 的 Web 服務，以及未來可能定義的其他設定檔。

識別提供者

同盟一開始會以身分識別的概念開始。 也就是說，要求者或要求者的委派 (身分識別提供者，該識別資料的授權擁有者) 判斷提示身分識別，而識別提供者會驗證此判斷提示。 然後同盟會成為信任的功能， (識別提供者之間的直接、代理和委派) ，以及依賴提供者判斷身分識別的人員。 有時候信賴憑證者需要能夠將來自多個提供者的身分識別相互關聯，例如，檢查上的身分識別相互關聯、信用卡和驅動程式的授權。

安全性權杖服務 (STS) 是一般服務，會使用一般模型和一組訊息來發行/交換安全性權杖。 因此，任何 Web 服務本身都可以是 STS，只要支援WS-Trust規格即可。 因此，有不同類型的安全性權杖服務可提供不同的補充服務。 識別提供者 (IP) 是一種特殊的安全性權杖服務類型，至少會執行對等實體驗證，而且可以在發行的安全性權杖中建立身分識別或聯盟宣告。 請注意，在許多情況下，IP 和 STS 是可交換的，而且本檔內的許多參考都會識別這兩者。

同盟模型是以WS-Trust中定義的架構為基礎，利用權杖發行和交換器制來包含發行和同盟身分識別。

下列範例說明 IP 和 STS 的可能組合，以存取服務。 在此範例中， (1) 要求者會從其 IP (Business456.com) 取得身分識別安全性權杖，然後向 Fabrikam123 的 STS 提供判斷提示 (安全性權杖) 。 如果 Fabrikam123.com 信任 Business456.com 並核准授權，STS 會將存取權杖傳回給要求者。 要求者 (3) 然後在要求上使用存取權杖來 Fabrikam123.com。

在此範例中，步驟 1 中的回應是由 Business456.com (信任的 IP) 簽署，而回應中傳回的安全性權杖會相對於 Fabrikam123.com (，例如它們) 發出。

下面討論的替代模型可讓服務 Fabrikam123.com 向假名服務註冊安全性權杖，並在需要時擷取此假名。 這可讓服務管理對應，但仍為要求者提供隱私權層級。

單一登入和Sign-Out

本檔和WS-Federation規格中所述的模型，允許不同的 使用者會話 概念，例如服務管理和要求者管理。 服務管理的會話其中一個範例是建立和管理網頁瀏覽器會話內的 Cookie。 要求者管理的會話範例是 Web 服務要求者，其會取得權杖並用一段時間，然後在到期前捨棄權杖。 引進 登出 的概念，以允許不同的設定檔指定這些轉換如何套用至每個設定檔。

單一登入的目的是建立存取同盟網域/領域 Web 內資源所需的安全性權杖。 同樣地， 同盟登出 是用來清除任何可能存在於同盟內的快取狀態和安全性權杖。 若要啟用這項功能，需要有機制，才能將識別提供者發出的同盟登入和登出訊息提供給已授權的登入和登出動作的授權者， (藉此允許他們執行任何必要的設定/清除動作) 。

屬性和假名

如先前所述，希望能夠取得身分識別 (或任何同盟資源的資訊) ，例如提供 「hello」 問候語或取得要求者的郵遞區號來個人化體驗 --這可由屬性服務提供。 此規格允許使用不同類型的屬性服務，例如 UDDI。

這類資訊必須受到授權規則和隱私權語意控管。 同樣地，預期不同的屬性會以不同的方式共用，並具有不同程度的隱私權和保護 (，例如名字與姓氏) 。 因此，每個屬性運算式都應該能夠表達自己的存取控制原則，而且原則應該將相關聯的範圍納入 () 和主體中，這些範圍可以代表範圍 () 。 例如，使用者 (人員) 可能想要設定下列專案：「我的內部網路中的服務可能可以存取我的姓氏，而其他服務則無法在我沒有明確許可權的情況下存取」。

屬性服務可能會利用現有的存放庫，並提供某種層級的組織或內容。 在組織命名空間中，會註冊個別主體，而且一組屬性屬性 (基本上是名稱/值組，其中名稱是字串屬性名稱，而值是 XML 中表示) XML 元素與主體相關聯。

請務必注意，每個屬性可能會有自己的安全性授權規則和隱私權原則，讓主體能夠控制誰以及資訊洩漏的方式。

不同的屬性服務有不同的功能，這些功能會以其原則檔表示。

除了屬性服務之外，也可能會有假 名服務。 假名服務可讓主體在不同的資源/服務或不同網域/領域有不同的 別名 。 某些識別提供者在其安全性權杖中使用固定身分識別。 在某些情況下，需要確保權杖的匿名性;假名提供啟用此匿名的機制。 管理能力通常取決於主體 (，也就是身分識別越多，管理問題) 的可能性就越大。

請注意，在某些情況下，屬性和假名服務將會合並，而在某些情況下，它們會是個別的服務。

例如，要求者會使用其主要身分識別 「Fred.Jones」 向 Business456.com 進行驗證。 不過，在 Fabrikam123.com，他稱為 「Freddo」。 若要保留匿名，Business456.com 可以在 Fred.Jones 登入時發出不同的身分識別，因此如下圖所示的步驟 3 顯示「匿名」。 Fabrikam123.com 可以在 Fabrikam123.com (步驟 4) ，並將 「Freddo」 設定為此要求者的本機名稱，並具有可瞭解匿名名稱的假名服務，以提供與 「Freddo」 的對應。

下一次要求者登入 Business456.com IP (步驟 1 下方) 時，可能會提供新的識別碼，例如 XYZ321@Business456.com 「」 (步驟 2 下方的步驟 2) 。 由於 Business456.com IP 具有上述的對應，因此 Fabrikam123.com 的 Web 服務現在可以在 Fabrikam123.com (步驟 4 要求的假名 XYZ321@Business456.com ，) 並取得先前設定的內容-在此情況下， (Freddo@Fabrikam123.com 步驟 5) 。

假名服務能夠執行這項操作，因為它能夠在 Business456.com 將 「 XYZ321@Business456.com 」 對應回已知身分識別，而該身分識別與不同的網域/領域相關聯。 此反向對應會根據 IP 與假名服務之間的信任關係進行。 同樣地，資源與假名服務之間的信任關係 (可能由 IP) 啟動，可讓資源獲得授權來取得和設定假名。

或者，識別提供者 (或 STS) 可以與假名服務手動操作。 也就是說，要求者會向指定的信任網域/領域或資源/服務要求其識別提供者 (或 STS) 要求權杖。 STS 會尋找假名，併發出可在指定資源/服務中使用的權杖，如下所示：

如圖所示，此同盟身分識別模型中支援幾種不同的方法，其中假名可用來協助維護隱私權。 每個都有不同的管理性和隱私權特性，讓每個提供者和主體選擇適當的解決方案以符合其特定需求。

4 摘要

在本檔中，我們建議整合式 Web 服務同盟模型，讓合作物件能夠發出並依賴來自其他同盟成員的資訊，並以安全的方式跨同盟代理信任和屬性，以維護個人和商務隱私權。

此模型會與 Web 服務安全性和相關規格整合，以在要求者和跨同盟內的服務之間啟用安全可靠的交易。

IBM 和 Microsoft 認為這是定義全方位 Web 服務安全性策略的重要步驟。  它反映到目前為止所識別的挑戰和解決方案。 當我們繼續與客戶、合作夥伴和標準組織合作以保護 Web 服務時，我們預期需要額外的想法和規格，才能完成策略。 

詞彙

由於術語在技術之間有所不同，因此本檔會定義數個可一致地套用到不同安全性格式和機制的詞彙。 因此，此處使用的術語可能會與其他規格不同，而且已定義，讓讀者可以將詞彙對應至慣用的詞彙。

被動瀏覽器 - 被動瀏覽器 是支援廣泛支援的 HTTP 瀏覽器 (，例如 HTTP/1.1) 。

作用中要求者 - 作用 中的 要求者 是一個應用程式 (可能是網頁瀏覽器) ，能夠發出 Web 服務訊息，例如 WS-Security 和 WS-Trust 中所述的訊息。

設定檔 - 設定檔 是說明此模型如何套用至特定類別的要求者 (檔，例如被動或主動) 。

宣告 - 宣告 是由實體 (所建立的宣告，例如名稱、身分識別、金鑰、群組、許可權、功能、屬性等) 。

安全性權杖 - 安全性權杖 代表宣告的集合。

已簽署的安全性權杖 - 已簽署的安全性權杖 是由特定授權單位 (以密碼編譯方式簽署的安全性權杖，例如 X.509 憑證或 Kerberos 票證)

擁有 - 權證明擁有權證明是一種驗證資料，其隨附訊息來證明訊息已傳送或由宣告的身分識別所建立。

擁有權證明權杖 - 擁有 權 證明權杖 是一種安全性權杖，其中包含傳送者可用來證明擁有權證明的資料。 一般而言，雖然並非獨佔，但擁有權證明信息會使用只有寄件者和收件者知道的金鑰來加密。

摘要 - 摘要 是八位資料流程的密碼編譯總和檢查碼。

簽 章 - 簽章 是使用密碼編譯演算法計算的值，並系結至資料的方式，讓預期的資料收件者可以使用簽章來確認資料自簽署後尚未變更。

安全性權杖服務 (STS) - 安全性權杖服務是發行安全性權杖 的 Web 服務， (請參閱 WS-Security 和 WS-Trust) 。 也就是說，它會根據它信任的辨識項，向信任者提出判斷提示。 若要通訊信任，服務需要證明，例如安全性權杖或一組安全性權杖，並使用自己的信任聲明發出安全性權杖， (請注意，對於某些安全性權杖格式，這可以是重新發行或共同簽章) 。 這會形成信任仲介的基礎。

屬性服務 - 屬性服務 是 Web 服務，可維護信任領域或同盟內主體 (屬性) 的資訊。 在此內容中，主體一詞可以套用至任何系統實體，而不只是人員。

假名服務 - 假 名服務 是 Web 服務，可維護信任領域或同盟內主體的替代身分識別資訊。 在此內容中，主體一詞可以套用至任何系統實體，而不只是人員。

信任 - 信任是一個實體願意依賴第二個實體來執行一組動作和/或，以針對一組主體和/或範圍做出一組判斷提示的特性。

信任網域 - 信任網域 是受管理的安全性空間，要求的來源和目標可以判斷及同意來源的特定認證集是否符合目標的相關安全性原則。 目標可能會延遲信任決策給協力廠商，因此在信任網域中包含受信任的協力廠商。

驗證服務 - 驗證服務 是一種 Web 服務，會使用WS-Trust機制來驗證提供的權杖，並評估其信任層級 (例如宣告信任) 。

直接信任 - 直接信任是當信賴憑證者接受為 true 時，所有 (或部分子集) 要求者所傳送權杖中的宣告。

直接代理信任 - 直接代理信任是當某一方信任第二方時，協力廠商會信任協力廠商的信任或擔保。

間接代理信任 - 間接代理信任是直接代理信任的變化，第二方無法立即向第一方驗證協力廠商宣告，並與協力廠商或其他合作物件交涉，以驗證宣告並評估協力廠商的信任。

訊息驗證 - 訊息驗證是確認收到的訊息與所傳送訊息相同的程式。

寄件者驗證 - 寄件者驗證是可能跨 Web 服務執行者/角色的驗證辨識項，指出 Web 服務訊息的寄件者 (及其相關聯的資料) 。 請注意，如果已驗證的媒介存在，訊息可能會有多個寄件者。 另請注意，它是應用程式相依 (和範圍外) ，其判斷第一次建立訊息為訊息來源者的人員可能無關，或隱藏在已驗證的寄件者後方。

領域或網域 - 領域 或 網域 代表單一安全性管理或信任單位。

同盟 - 同盟 是已建立信任的領域/網域集合。 信任層級可能會有所不同，但通常包含驗證，而且可能包含授權。

識別提供者 - 識別提供者是一個實體，可做為終端使用者的對等實體驗證服務，並將資料來源驗證服務提供給服務提供者， (這通常是安全性權杖服務的延伸) 。

單一登入 (SSO) - 單一登入是驗證順序的優化，可移除對使用者所放置重複動作的負擔。 為了協助 SSO，稱為識別提供者的專案可以代表使用者作為 Proxy，向協力廠商提供驗證事件的辨識項給要求使用者相關資訊的協力廠商。 這些識別提供者是受信任的協力廠商，而且使用者 (必須信任這兩者，才能維護使用者的身分識別資訊，因為遺失此資訊可能會導致使用者身分識別) 和 Web 服務遭到入侵，這些服務可能會根據 IP 所提供的身分識別資訊完整性來授與重要資源和資訊的存取權。

身分識別對應 - 身分識別對應是建立身分識別屬性之間關聯性的方法。 某些識別提供者可能會使用識別碼對應。

登出 - 登出 是針對領域/網域或同盟終結安全性權杖的程式。

協會 - 關聯是主體變成與信任領域或同盟建立關聯或關聯的程式。

參與者

本檔是由 IBM 和 Microsoft 共同撰寫。

主要貢獻包括依字母順序) (：Giovanni Della-Libera、Microsoft;Brendan Dixon，Microsoft;Mike Dusche， Microsoft;Don Ferguson， IBM;Praerit Garg、Microsoft;Tim Hahn， IBM;Heather Hinton，IBM;Maryann Hondo，IBM;Chris Kaler，Microsoft;Frank Leymann， IBM;Brad Lovering，Microsoft;在 IBM;Anthony Nadalin， IBM;Nataraj Nagaratnam，IBM;Venkat Raghavan， IBM;John Shewchuk，Microsoft

參考資料

© 2001-2003 International Business Machines Corporation， 。 著作權所有，並保留一切權利。

這是初步檔，可能會隨著時間大幅變更。 本檔中包含的資訊代表國際商務電腦和 Microsoft Corporation 目前有關發行日期所討論的問題檢視。 由於 IBM 和 Microsoft 必須回應不斷變化的市場狀況，因此不應將它解譯為 IBM 和 Microsoft 部分的承諾，而 IBM 和 Microsoft 無法保證發行日期之後所呈現之任何資訊的精確度。

本檔中所含資訊的簡報、散發或其他資訊，不是明確或隱含地授權給 IBM 或 Microsoft 以及\或任何其他協力廠商所擁有或控制的智慧財產權。  IBM、Microsoft 和\或任何其他協力廠商可能擁有涵蓋本檔中主體的專利、專利應用程式、商標、著作權或其他智慧財產權。  本檔不授與 IBM 或 Microsoft 或任何其他協力廠商專利、商標、著作權或其他智慧財產權的任何授權。 此處所描述的範例公司、組織、產品、網域名稱、電子郵件地址、商標、人員、地點與事件均屬虛構。  並非影射任何真實的公司、組織、產品、網域名稱、電子郵件地址、商標、人員、地點或事件。

本檔及本文所包含的資訊是以「AS IS」為基礎提供，而且根據適用法律允許的最大範圍，IBM 和 Microsoft 會提供 AS IS 和 WITH ALL FAULTS 檔，並藉由明示、隱含或法律等所有其他擔保和條件，包括但不限於任何) 隱含擔保的任何 (， 責任或條件、符合特定用途的適用性、回應正確性或完整性、結果、工作工作、缺乏病毒，以及缺乏過失，全都與檔有關。 此外，沒有關于檔之任何智慧財產權的描述或違規、無訊息擁有權、無訊息擁有權、無聲擁有權、不違反任何智慧財產權的擔保或條件。

在任何情況下，IBM 或 MICROSOFT 對於購買替代商品或服務、遺失收益、使用損失、資料遺失或任何附加、衍生、直接、間接或特殊損害，不論合約、TORT、保固或其他任何相關合約，都可能因本檔或任何其他合約而產生任何責任， 不論這類合作物件是否事先通知這類損害的可能性。