共用方式為

Web 服務世界中的安全性：建議的架構和藍圖

  • 發行項

 

2002 年 4 月 7 日
1.0 版

© 2001-2002 年 國際商業機器公司， 。 保留所有權利。

這是一份初步檔，可能會隨著時間而大幅變更。 本檔所包含的資訊代表目前對國際商務機器和Microsoft公司關於發行日期所討論的問題的看法。 由於IBM和Microsoft必須響應不斷變化的市場狀況，因此不應解釋為IBM和 Microsoft 的承諾，IBM 和 Microsoft無法保證發行日期之後呈現的任何資訊的正確性。

本檔中所含資訊的展示、散發或其他傳播，不是IBM或Microsoft或任何其他第三方所擁有或控制的智慧財產權的授權或隱含。 IBM、Microsoft及\或任何其他第三方可能擁有本文件中涵蓋主體的專利、專利申請、商標、著作權或其他智慧財產權。 本檔提供給您任何授權給 IBM 或Microsoft或其他第三方專利、商標、著作權或其他智慧財產權。 此處所描述的範例公司、組織、產品、功能變數名稱、電子郵件地址、標誌、人員、地點和事件都是虛構的。 與任何實際公司、組織、產品、功能變數名稱、電子郵件地址、標誌、人員、地點或事件沒有任何關聯，或應該推斷。

本檔及本文所包含的資訊是以「AS IS」為基礎提供，而且在適用法律允許的最大範圍內，IBM 和Microsoft會提供檔 AS IS AND WITH ALL FAULTS，並因此不披露所有其他擔保和條件，包括明示、默示或法定，包括但不限於任何（如果有）默示擔保， 工作或條件適銷性、符合特定目的、正確性或回應完整性、結果、工作工作、缺乏病毒和缺乏疏忽，都與文件有關。 此外，對於檔的任何智慧財產權的描述或 NON-INFRINGEMENT，沒有擁有權、安靜享受、安靜擁有、無聲財產權的擔保或條件。

無論根據合約、侵權、擔保或其他任何協定，IBM 或MICROSOFT都須向任何其他方承擔採購替代商品或服務的費用、損失利潤、使用損失、數據損失或任何附帶性、衍生性、直接、間接或特殊損害，不論是根據合約、侵權、保固或其他任何原因，都因本檔的任何其他合約而產生。 該方是否事先通知了此類損害的可能性。

抽象

本文件說明解決 Web 服務環境內安全性的建議策略。 它定義完整的 Web 服務安全性模型，可支援、整合和統一數種熱門的安全性模型、機制和技術（包括對稱和公鑰技術），讓各種系統以平臺和語言中性的方式安全地互操作。 它也會描述一組規格和案例，示範這些規格如何一起使用。

摘要

IT 產業已經談論 Web 服務近兩年了。 在組織內部、跨企業和因特網之間連結應用程式時，以鬆散結合、語言中立、平台無關的方式，隨著 Web 服務用於試驗計劃和大規模生產環境，其優點變得越來越明顯。 接下來，我們的客戶、產業分析師和媒體會識別需要解決的重要領域，因為 Web 服務會變得更加主流：安全性。 本檔提出了一項技術策略和藍圖，讓業界能夠產生並實作一種以標準為基礎的架構，該架構具有完整的彈性，足以滿足真實企業的Web服務安全性需求。

新興 Web 服務架構的主要優點是能夠提供整合、互通的解決方案。 透過全面安全性模型的應用，確保 Web 服務的完整性、機密性和安全性，對於組織及其客戶而言都是重要的。

針對我們的客戶和業界所表達的擔憂，IBM 和Microsoft已就此建議的Web服務安全性計畫和藍圖共同作業，以開發一組Web服務安全性規格，以解決如何為Web服務環境中交換的訊息提供保護。

我們第一次建立了一個安全性模型，將先前不相容的安全性技術整合在一起，例如公鑰基礎結構、Kerberos 和其他技術。 簡言之，這不是理想的架構，而是一個實用的架構，可讓我們在現今客戶所在的異質 IT 世界中建置安全的 Web 服務。

在本檔中，我們提供了一組廣泛的規格，涵蓋安全性技術，包括驗證、授權、隱私權、信任、完整性、機密性、安全通訊通道、同盟、委派和稽核，以及各種應用程式和商務拓撲。 這些規格提供可延伸、彈性且最大化現有安全性基礎結構投資的架構。 這些規格會細分並擴展IBM先前提出的類似規格和Microsoft所表達的想法（即SOAP-Security、WS-Security 和 WS-License 規格）。

藉由利用 Web 服務模型核心的自然擴充性，規格會以 SOAP、WSDL、XML 數位簽名、XML 加密和 SSL/TLS 等基礎技術為基礎而建置。 這可讓 Web 服務提供者和要求者開發符合其應用程式個別安全性需求的解決方案。

IBM 和Microsoft打算與客戶、合作夥伴和標準機構合作，以分階段方式發展及改善此安全性模型。 我們會使用 WS-Security 規格植入這項工作。 WS-Security 會定義保護訊息完整性和機密性的核心設施，以及將安全性相關宣告與訊息產生關聯的機制。 雖然 WS-Security 是這項工作的基石，但它只是一個開始，我們將與業界合作，產生額外的規格，以處理政策、信任和隱私權問題。

為了盡可能具體地討論本檔所討論的問題和解決方案，我們會討論反映Web服務目前和預期應用程式的數個案例。 其中包括防火牆處理、隱私權、瀏覽器和行動用戶端的使用、訪問控制、委派和稽核。

我們預期會擔心可以做些什麼，以確保各種建議規格的互操作性和一致實作。 為了解決這個問題，IBM 和Microsoft將與標準組織、開發人員社群和產業組織密切合作，例如 WS-I.org 開發互操作性配置檔和測試，為工具廠商提供指引。

本檔概述一個全面的模組化解決方案，在實作時，可讓客戶建置可互通且安全的Web服務，以利用並擴充現有安全性基礎結構的投資，同時讓他們充分利用Web服務技術所提供的整合和互操作性優勢。

1 簡介和動機

為 Web 服務提供安全性功能與元件的完整模型，需要整合目前可用的程式和技術，以及未來應用程式不斷演進的安全性需求。 它要求統一概念：它需要解決技術（安全傳訊）和商務程式（原則、風險、信任）問題的解決方案：最後，它需要平臺廠商、應用程式開發人員、網路和基礎結構提供者和客戶協調努力。

統一可用的安全性技術範圍，表示必須從採用的特定機制中抽象化應用程式安全性的功能需求。 例如，客戶進行在線購買不應受到使用手機或膝上型計算機的影響，只要每部裝置都能安全地表達適當的身分識別。

目標是讓客戶能夠使用異質系統輕鬆地建置互通的解決方案。 例如，本檔稍後提出的安全傳訊模型支援公鑰基礎結構（PKI）和 Kerberos 身分識別機制，作為更通用設施的特定體現，而且能夠擴充以支援額外的安全性機制。 透過單一安全性模型的抽象概念進行整合，可讓組織使用其現有的安全性技術投資，同時使用不同的技術與組織通訊。

此外，當使用不同身分識別機制的組織使用 Web 服務共同作業時，安全性信任模型會提供彈性的架構，讓組織在設定適當的授權時相互連線。

同時，每個客戶和每個 Web 服務都會根據其特定商務需求和作業環境，有自己的獨特安全性需求。 例如，在工作組設定中，簡單且容易運作是首要考慮，而公用因特網應用程式則能夠承受一致的阻斷服務攻擊是較高優先順序。 由於這些需求可能會以許多方式結合，並以不同層級的明確性表示，因此 Web 服務安全性的成功方法需要一組彈性、互通的安全性基本類型，透過原則和設定來啟用各種安全解決方案。

為了解決這些挑戰，本檔提出了一種進化方法，根據一組統一先前不同技術的安全性抽象概念來建立安全互通的Web服務。 這可讓特製化在整體架構內的特定客戶需求，同時允許技術隨著時間演進並累加部署。

作為這個進化方法的範例，安全傳訊模型可以新增至現有的傳輸層級安全性解決方案。 客戶可以將訊息層級完整性或永續性機密性（訊息元素加密）新增至現有的 Web 服務，其訊息會透過安全套接字層 （SSL/TLS） 傳遞。 訊息現在具有保存於傳輸層以外的完整性（或機密性）。

我們預期所提議的模型和規格將廣泛提供給多個廠商使用，並由適當的標準組織考慮。 一起，模型、規格和標準程式可讓企業快速且符合成本效益地提高現有應用程式的安全性，並自信地開發新的互通、安全的Web服務。

這類模型的商務優勢很明顯。 藉由為 Web 服務建構完整的安全性架構，組織與客戶可以更妥善地確保其投資和資產在商務程式隨著 Web 服務逐漸重新廣播而受到保護。

Web 服務安全性模型術語

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

  • Web 服務—「Web 服務」一詞廣泛適用於各種網路型應用程式拓撲。 在本檔中，我們使用「Web 服務」一詞來描述其功能和介面透過使用 XML、SOAP、WSDL 和 HTTP 等現有和新興 Web 技術標準，向潛在使用者公開的應用程式元件。 相較於網站、瀏覽器型互動或平臺相依技術，Web 服務是透過平臺獨立和語言中性方式，透過定義的格式和通訊協定提供計算機對計算機的服務。

  • 安全性令牌— 我們將安全性令牌定義為安全性相關信息的表示法（例如 X.509 憑證、Kerberos 票證和驗證器、SIM 卡、使用者名稱等的行動裝置安全性令牌）。

    下圖顯示一些不同類型的安全性令牌。

  • 已簽署的安全性令牌— 我們將 已簽署的安全性令牌定義為安全性令牌 定義為安全性令牌，其中包含簽發者以密碼編譯方式背書的一組相關宣告（判斷提示）。 已簽署安全性令牌的範例包括 X.509 憑證和 Kerberos 票證。

  • 宣告— 宣告是由主體或與宣告建立關聯之另一方關於主體的陳述。 重點是，此規格不會嘗試限制可進行的宣告類型，也不會嘗試限制這些宣告的表達方式。 宣告可以是可能用來簽署或加密訊息的金鑰。 宣告可以是安全性令牌所傳達的語句。 例如，宣告可用來判斷傳送者身分識別或授權角色。

  • 主體— 安全性令牌的主體是主體（例如人員、應用程式或商業實體），其宣告在安全性令牌中表示。 具體來說，主體是安全性令牌的擁有者擁有證明安全性令牌擁有權所需的資訊。

  • 控權證明—我們會定義 擁有證明，以證明安全性令牌或一組宣告的擁有權過程中使用的資訊。 例如，擁有權證明可能是與包含公鑰之安全性令牌相關聯的私鑰。

  • Web 服務端點原則—Web 服務在指定宣告時具有完整的彈性，以處理訊息。 我們共同將這些必要的宣告和相關信息稱為「Web 服務端點原則」。 端點原則可以用 XML 表示，而且可用來指出與驗證相關的需求（例如使用者或群組身分識別證明）、授權（例如特定執行功能證明）或其他自定義需求。

  • 宣告需求—宣告需求可以系結至整個訊息或訊息元素、指定類型的所有動作，或只在特定情況下才系結至動作。 例如，服務可能需要要求者證明購買金額大於指定限制的授權單位。

  • 中繼程式— 因為 SOAP 訊息是從初始要求者傳送至服務，所以執行路由訊息，甚至修改訊息等動作的媒介可能會操作它們。 例如，媒介可能會新增標頭、加密或解密訊息片段，或新增其他安全性令牌。 在這種情況下，應小心處理，使郵件的變更不會使訊息完整性失效、違反信任模型，或終結責任。

  • 動作專案—動作專案 是中繼或端點（如 URI 和處理 SOAP 訊息的 SOAP 規格中所定義）。 請注意，使用者和用戶端軟體（例如瀏覽器）都不是動作專案。

Web 服務安全性模型原則

Web 服務可藉由將SOAP訊息傳送至URI所識別的服務端點、要求特定動作，以及接收SOAP訊息回應（包括錯誤指示）。 在此內容中，保護 Web 服務的廣泛目標會細分為提供保護訊息完整性和機密性之設施的附屬目標，並確保服務只會在表達原則所需宣告的訊息中要求上運作。

目前，安全套接字層（SSL），以及事實上的傳輸層安全性（TLS）用於為 Web 服務應用程式提供傳輸層級安全性。 SSL/TLS 提供數個安全性功能，包括驗證、數據完整性和數據機密性。 SSL/TLS 可啟用點對點安全會話。

IPSec 是傳輸安全性的另一個網路層標準，對於Web服務而言可能變得很重要。 與 SSL/TLS 一樣，IPSec 也提供主機驗證、數據完整性和數據機密性的安全會話。

現今的 Web 服務應用程式拓撲包括行動裝置、閘道、Proxy、負載平衡器、非軍事區域（DMZ）、外包數據中心，以及全域分散式動態設定的系統的組合。 所有這些系統都依賴訊息處理媒介轉送訊息的能力。 具體而言，SOAP 訊息模型會在邏輯端點上運作，以抽象化實體網路和應用程式基礎結構，因此經常將多躍點拓撲與中繼動作項目合併。

當傳輸層以外的中繼端接收和轉送數據時，數據的完整性以及可能遺失的任何安全性資訊。 這會強制任何上游訊息處理器依賴先前中繼所進行的安全性評估，並完全信任其處理訊息的內容。 完整的 Web 服務安全性架構需要的是一種提供端對端安全性的機制。 成功的 Web 服務安全性解決方案將能夠利用傳輸和應用層安全性機制，提供完整的安全性功能套件。

點對點設定

端對端設定

本文所述的 Web 服務安全性模型可讓我們透過下列程式達成這些目標：

  • Web 服務可以要求傳入訊息證明一組 宣告（例如名稱、金鑰、許可權、功能等）。 如果訊息到達時沒有必要的宣告，服務可能會忽略或拒絕訊息。 我們將一組必要的宣告和相關信息稱為 原則。
  • 要求者可以藉由將 安全性令牌 與訊息產生關聯，來傳送具有必要宣告證明的訊息。 因此，訊息都需要特定動作，並證明其寄件者有要求動作的宣告。
  • 當要求者沒有必要的宣告時，要求者或代表其人員可以透過連絡其他 Web 服務來嘗試取得必要的宣告。 這些其他 Web 服務，我們稱之為 安全性令牌服務，可能接著需要自己的一組宣告。 藉由發出安全性令牌，在不同的信任網域之間代理安全性令牌服務代理信任。

下圖說明此模型，其中顯示任何要求者也可能是服務，而且安全性令牌服務也可能完全是 Web 服務，包括表示原則和要求安全性令牌。

此一般傳訊模型 —宣告、原則和安全性令牌— 會細分並支持數個更特定的模型，例如身分識別型安全性、訪問控制清單和功能型安全性。 它允許使用現有的技術，例如 X.509 公鑰憑證、Kerberos 共用密碼票證，甚至是密碼摘要。 如稍後我們將討論，它也會提供整合抽象概念，讓系統在不同的安全性技術之間建立橋樑。 一般模型足以建構較高層級的密鑰交換、驗證、授權、稽核和信任機制。

2 Web 服務安全性規格

此處所表示的安全性策略和下面引進的 WS-Security 規格，為這個建議的Web服務安全性模型提供戰略目標和基石。

接下來，我們會繼續與客戶、合作夥伴和標準組織合作，以開發一組初始的 Web 服務安全性規格。

此集合將包含訊息安全性模型 （WS-Security），以提供其他安全性規格的基礎。 在此分層上，我們有一個原則層，包括 Web 服務端點原則（WS-Policy）、信任模型（WS-Trust），以及隱私權模型（WS-Privacy）。 這些初始規格一起提供基礎，讓我們能夠跨信任網域建立安全互通的 Web 服務。

根據這些初始規格，我們將繼續與客戶、合作夥伴和標準組織合作，為同盟安全性提供後續規格，包括安全交談（WS-SecureConversation）、同盟信任（WS-Federation）和授權（WS-Authorization）。

這些安全性規格的組合可啟用許多案例（本檔稍後會說明其中一些案例），這些案例難以透過現今的較基本安全性機制來實作。

同時，我們將提出並推進相關活動，以增強 Web 服務安全性架構，並指定與稽核、管理和隱私權相關的規格。

此外，IBM 和Microsoft致力於與 WS-I 互操作性配置檔等組織合作。

安全性規格、相關活動和互操作性配置檔的組合，可讓客戶輕鬆地建置可互通的安全 Web 服務。

每個建議的規格摘要如下：

初始規格

  • WS-Security：描述如何將簽章和加密標頭附加至SOAP訊息。 此外，它描述如何將安全性令牌，包括 X.509 憑證和 Kerberos 票證等二進位安全性令牌附加至訊息。
  • WS-Policy：將描述中繼和端點上安全性（和其他商務）原則的功能和限制（例如必要的安全性令牌、支援的加密演算法、隱私權規則）。
  • WS-Trust：將描述可讓 Web 服務安全地互通的信任模型架構。
  • WS-Privacy：將描述 Web 服務和要求者狀態隱私權喜好設定和組織隱私權實務聲明的模型。

Follow-On 規格

  • WS-SecureConversation：將說明如何管理和驗證合作對象之間的訊息交換，包括安全性內容交換和建立和衍生會話密鑰。
  • WS-Federation：將說明如何在異質同盟環境中管理及代理信任關係，包括對同盟身分識別的支援。
  • WS-Authorization：將說明如何管理授權數據和授權原則。

為 WS-Security 提供安全性，需要對一些功能區域中的描述、規格和配置檔生產進行盡職盡責。 這些檔將透過一個程式來變更和演進，以平衡客戶的需求與 Web 服務開發社群的需求，以及我們在進行規格程式時自己的教育程式。

WS-Security

WS-Security 說明 SOAP 傳訊的增強功能，透過訊息完整性和訊息機密性提供 保護 品質。 此規格也會定義如何在SOAP訊息中附加和包含安全性令牌。 最後，提供一個機制來指定二進位編碼的安全性令牌（例如 X.509 憑證）。 這些機制可以獨立使用或結合，以容納各種不同的安全性模型和加密技術。

WS-Security 提供一般用途機制，讓安全性令牌與訊息產生關聯。 WS-Security不需要特定的安全性令牌類型。 其設計目的是可延伸（例如支援多個安全性令牌格式）。 例如，要求者可能會提供身分識別證明，以及證明他們具有特定商務認證。

訊息完整性是利用 XML 簽章 搭配安全性令牌（可能包含或暗示金鑰資料）來提供，以確保訊息未經修改即可傳輸。 完整性機制的設計訴求是支援多個簽章，可能是由多個動作專案所設計，而且可擴充以支援其他簽章格式。 簽章可以參考安全性令牌（亦即指向）。

同樣地，訊息機密性是利用 XML 加密 搭配安全性令牌來保留SOAP訊息的機密部分。 加密機制的設計目的是要支援多個執行者的其他加密技術、程序和作業。 加密也可以參考安全性令牌。

最後，WS-Security 描述編碼二進位安全性令牌的機制。 具體來說，規格說明如何編碼 X.509 憑證和 Kerberos 票證，以及如何包含不透明的加密密鑰。 它也包含擴充性機制，可用來進一步描述訊息隨附的安全性令牌特性。

WS-Policy

WS-Policy 將說明傳送者和接收者如何指定其需求和功能。

WS-Policy 將完全可延伸，而且不會限制可能描述的需求和功能類型：不過，規格可能會識別數個基本服務屬性，包括隱私權屬性、編碼格式、安全性令牌需求和支持的演算法。

此規格將定義一般 SOAP 原則格式，其不僅可支援安全策略。 此規格也會定義連結或關聯服務原則與SOAP訊息的機制。

WS-Trust

WS-Trust 將描述建立直接和代理信任關係（包括第三方和媒介）的模型。

此規格將說明如何透過建立安全性令牌發行服務，將現有的直接信任關聯性作為代理信任的基礎。 這些安全性令牌發行服務建置在 WS-Security，以確保這些令牌的完整性和機密性的方式傳輸必要的安全性令牌。

然後，此規格將說明如何搭配此信任模型使用數個現有的信任機制。

最後，信任模型將明確允許，但不會授權、委派和模擬主體。 請注意，委派與模擬一致，但提供額外的可追蹤層級。

WS-Privacy

建立、管理及使用 Web 服務的組織通常需要陳述其隱私策略，並要求連入要求提出寄件者遵守這些原則的宣告。

藉由使用 WS 原則的組合，WS-Security和 WS-Trust，組織可以陳述並指出符合已陳述的隱私策略。 此規格將說明隱私權語言如何內嵌至 WS-Policy 描述的模型，以及如何使用 WS-Security 來將隱私權宣告與訊息產生關聯。 最後，此規格將說明如何使用 WS-Trust 機制來評估使用者喜好設定和組織實務宣告的這些隱私權宣告。

WS-SecureConversation

WS-SecureConversation 將說明 Web 服務如何驗證要求者訊息、要求者如何驗證服務，以及如何建立相互驗證的安全性內容。

此規格將說明如何建立會話密鑰、衍生金鑰和每個訊息金鑰。

最後，此規格將說明服務如何安全地交換內容（安全性屬性和相關數據的宣告集合）。 為了達成此目的，此規格將描述及建置 WS-Security 和 WS-Trust 中定義的安全性令牌發行和交換機制概念。 例如，使用這些機制，服務可能會支援使用弱式對稱密鑰技術的安全性令牌，以及使用非共用（非對稱）密鑰發出更強的安全性令牌。

WS-SecureConversation 的設計目的是在SOAP訊息層運作，讓訊息可以周遊各種傳輸和媒介。 這不會排除其在其他傳訊架構內的使用。 為了進一步提高系統的安全性，傳輸層級安全性可以搭配 WS-Security 和跨選取連結 WS-SecureConversation 使用。

WS-Federation

此規格將定義如何使用 WS-Security、WS-Policy、WS-Trust 和 WS-SecureConversation 規格來建構同盟信任案例。 例如，它會描述如何同盟 Kerberos 和 PKI 基礎結構（如下列案例所述）。

同時，也會引入信任原則來指出和限制和識別所代理的信任類型。

此規格也會定義管理信任關係的機制。

WS-Authorization

此規格將說明如何指定和管理 Web 服務的存取原則。 特別是，它會描述如何在安全性令牌內指定宣告，以及如何在端點解譯這些宣告。

此規格的設計目的是在授權格式和授權語言方面具有彈性且可擴充性。 這可啟用各種不同的案例，並確保安全性架構的長期可行性。

3 將 Web 服務安全性與現今的安全性模型建立關聯

此 Web 服務安全性模型與目前常用的驗證、數據完整性和數據機密性現有的安全性模型相容。 因此，可以將 Web 服務型解決方案與其他現有的安全性模型整合：

  • 傳輸安全性—安全套接字（SSL/TLS）等現有技術可為訊息提供簡單的點對點完整性和機密性。 Web 服務安全性模型支援使用這些現有的安全傳輸機制搭配 WS-Security（和其他規格），以提供端對端完整性，特別是跨多個傳輸、中繼和傳輸通訊協定。
  • PKI—高階而言，PKI 模型牽涉到證書頒發機構單位頒發具有公開非對稱密鑰的憑證，以及判斷密鑰擁有權以外的屬性的證書頒發機構單位（例如屬性授權單位）。 這類憑證的擁有者可以使用相關聯的密鑰來表達各種宣告，包括身分識別。 Web 服務安全性模型支援使用公用非對稱密鑰發行安全性令牌的安全性令牌服務。 PKI 在此以最廣泛的方式使用，且不會假設任何特定的階層或模型。
  • Kerberos— Kerberos 模型依賴與密鑰發佈中心 （KDC） 的通訊，藉由為雙方發出加密的對稱密鑰，並「互相引進」它們，以代理雙方之間的信任。 Web 服務模型再次以具有安全性令牌服務代理信任的核心模型為基礎，方法是使用加密的對稱密鑰和加密證明來發行安全性令牌。

請注意，雖然模型相容，但為了確保簽章和加密的互操作性、配接器和/或一般演算法都必須在或開發時達成一致。

同盟、授權（包括委派）、隱私權和信任的現有模型較不常見，更臨機操作。 這些安全性屬性的規格會在策略的後續階段中識別。

現有的信任模型通常是以商務協定為基礎。 其中一個範例是 UDDI Web 服務。 在UDDI中，有數個參與者透過合約提供通用商務登錄，以支援一組 API。 UDDI 中的「信任模型」不是透過特定驗證機制的需求來定義「信任」的單一模型，而是將驗證責任授與節點，也就是資訊的監管人。 也就是說，UDDI Web 服務的每個實作都有自己的驗證機制，並強制執行自己的訪問控制原則。 「信任」位於運算符之間，以及要求者與其資訊監管人之間的「信任」。

4 個案例

以下是一些案例，這些案例會示範我們設想使用的建議Web服務安全性規格的方式。 這些案例會刻意著重於技術詳細數據，以說明整體安全性策略的功能。 將會有隨附檔，提供詳細的商務使用案例。

此處描述的範例公司、組織、產品、功能變數名稱、電子郵件地址、標誌、人員、地點和事件都是虛構的。與任何實際公司、組織、產品、功能變數名稱、電子郵件地址、標誌、人員、地點或事件沒有任何關聯，或應該推斷。

下列清單簡短介紹一些案例，這些案例可由建議的初始規格和相關聯的交付項目支援：

  • 使用使用者名稱/密碼和 Transport-Level 安全性的直接信任 — 此案例說明使用具有傳輸安全性的使用者名稱和密碼進行驗證。
  • 使用安全性令牌的直接信任 — 此案例說明使用 X.509 認證和 Kerberos 服務票證的直接信任。ST。
  • 安全性令牌擷取 - 此案例說明使用與訊息獨立儲存的安全性令牌進行驗證。
  • 防火牆處理 — 此案例說明防火牆如何利用此安全性模型，以取得更大的控制程度。
  • 已發行的安全性令牌 - 此案例說明基本身份驗證。
  • 強制執行商務原則 — 此案例說明如何使用安全性令牌發行來編纂商務程式。
  • 隱私權—此案例說明客戶端和服務如何傳達其隱私策略。
  • Web 用戶端 — 此案例說明使用網頁瀏覽器做為用戶端。
  • 行動用戶端 - 此案例說明行動用戶端如何安全地與 Web 服務互動。

第二組案例更為複雜。 這些案例可以建置在目前的交付專案上，但需要後續規格（例如 WS-SecureConversation），才能讓互操作性順暢。

  • 啟用同盟 — 本節描述數個不同的案例，涉及同盟信任。
  • 驗證服務：描述如何使用驗證訊息安全性的服務（例如簽章）。
  • 支援委派 — 這說明如何使用安全性令牌進行委派。
  • 存取控制 — 這說明 Web 服務安全性如何支援傳統存取控制清單型安全性。
  • 稽核 - 這說明如何使用稽核來追蹤安全性相關活動和事件。

請注意，在下方的描述中，使用「要求者」一詞來描述Web服務的各種潛在使用者，並不適合限制要求者的特性。 要求者可以包含與 B2B 環境內服務互動的商業實體，或從瀏覽器或行動裝置存取服務的個人或人員。

使用使用者名稱/密碼和 Transport-Level 安全性的直接信任

以下是一個非常基本的範例，示範 Web 服務安全性如何搭配現有的傳輸安全性機制使用：

要求者會使用安全傳輸來開啟 Web 服務的連線（例如 SSL/TLS）。 它會傳送其要求，並包含包含其使用者名稱和密碼的安全性令牌。 服務會驗證資訊、處理要求，並傳回結果。

在此案例中，訊息機密性和完整性是使用現有的傳輸安全性機制來處理。

此案例假設雙方已使用一些機制來建立共享密碼，也就是要求者密碼。 沒有對這些合作對象之間的組織關係做出任何假設。

使用安全性令牌的直接信任

此案例說明如何使用 Web 服務直接信任的安全性令牌。 這裡直接信任表示要求者的安全性令牌（或其簽署授權單位）已知且受到 Web 服務信任。 此案例假設雙方已使用一些機制來建立信任關係，以使用安全性令牌。 您可以手動建立此信任，方法是設定應用程式，或使用安全的傳輸來交換密鑰。 藉由安全傳輸金鑰，我們表示 SSL 等傳輸（或其他機制或程式）可作為信任方判斷密鑰或安全性令牌對收件者有效的方法。 雙方之間沒有關於組織關係的假設。

要求者會將訊息傳送至服務，並包含已簽署的安全性令牌，並提供安全性令牌的擁有證明，例如簽章。 服務會驗證證明並評估安全性令牌。 安全性令牌上的簽章有效，而且服務會直接信任。 服務會處理要求並傳回結果。

直接信任假設相關各方已充分了解隱私策略。

安全性令牌取得

在某些情況下，使用的安全性令牌不會作為訊息的一部分傳遞。 而是會提供安全性令牌參考，可用來尋找和取得令牌。

要求者向服務發出要求，並包含安全性令牌的參考，並提供擁有證明。 Web 服務會使用提供的資訊，從令牌存放區服務取得安全性令牌，並驗證證明。 Web 服務信任 （請注意，信任是在訊息語意外部建立的）安全性令牌，因此會處理要求並傳回回應。

防火牆處理

防火牆仍然是 Web 服務安全性架構的重要元件，它們必須能夠繼續強制執行界限處理規則。

如下所示，防火牆會檢查傳入的SOAP訊息，並只允許來自「已授權」要求者的訊息滲透防火牆。

在此案例中，我們有兩個要求者將訊息傳送至防火牆內的Web服務。 防火牆會檢查訊息，以判斷要求者是否「已授權」將訊息傳送至防火牆內的指定Web服務。

在此案例中，防火牆會藉由檢查用來簽署訊息的安全性令牌來進行此決策。 如果簽章有效，且信任安全性令牌的簽署授權單位來授權訊息進入防火牆，且令牌表示它會授權訊息進入防火牆，則允許訊息;否則會遭到拒絕。 在某些情況下，簽章可能會特別將防火牆參考為SOAP動作專案。

在其他情況下，防火牆也可以作為安全性令牌發行授權單位，只允許包含防火牆所簽發之安全性令牌的擁有證明的訊息。

已發行的安全性令牌

以下範例顯示 Web 服務安全性如何支援信任方進行簡單驗證：

在前兩個步驟中，要求者會與認證授權單位通訊以取得安全性令牌，特別是證明要求者身分識別之判斷提示的已簽署聲明。

要求者取得安全性令牌，因為 Web 服務有原則要求需要適當類型的安全性令牌（在此案例中為身分識別證明）。

要求者接著會將安全性令牌和附加至訊息的擁有證明傳送給 Web 服務，並接收回應。

請注意，在上述描述中，未詳細說明身分識別認證服務的作業。 若要取得身分識別安全性令牌，要求者可以使用現有的安全性通訊協定，或者可能會利用 Web 服務安全性規格。

如果我們假設要求者使用 Web 服務安全性規格，則系統會如下所示運作：身分識別服務會描述其在原則中的需求，而要求者接著可以要求安全性令牌及其身分識別證明。

請注意，身分識別服務只是安全性令牌服務。 此外，Web 服務的對稱性可讓任何 Web 服務也封裝安全性令牌服務。

最後，請注意，Web 服務可以代表要求者取得安全性令牌（從安全性令牌服務），並將它們傳回給要求者，以供後續訊息使用。

強制執行商務原則

在許多商務程式中，必須強制執行特定的原則。 例如，服務可能要求取用者具有特定評等或與特定稽核公司一起。 透過 Web 服務，許多這些原則都可以自動編纂和驗證，以簡化整體程式。

請考慮下列範例：

尼古拉斯的轉銷商有一個 Web 服務，用於與其零件供應商互動。 不過，他們只想要處理由製造商認證其零件的供應商。

約書亞的零件公司將前往製造商，並出示（並證明）其身分識別安全性令牌（例如，從說明的安全性令牌服務），並要求製造商的安全性令牌，指出他們是經過認證的零部件轉銷商（假設他們經過認證且處於良好地位）。 約書亞的零件可以聯繫尼古拉斯的轉銷商，並提供（並證明）這兩個安全令牌。

如果尼古拉斯的轉銷商將他們的商業政策編入服務政策，政策一致性的負擔可能會預先載入到零部件公司（例如約書亞的零件）。

服務原則也可以指定允許製造商儲存哪些資訊的條件約束，以確保符合隱私策略。

隱私

隱私權包含一組廣泛的考慮，而且必須在從此策略產生的每個規格中納入考慮。

在服務原則內提供隱私聲明，即可解決基本隱私權問題。 更複雜的案例，涉及委派和授權，將涵蓋在這些案例的特定規格中。

例如，個人會陳述一組「隱私權喜好設定」，描述個人的行為或不想允許代表個人執行的應用程式使用個人資訊。 行事曆應用程式，代表個人工作，現在可以存取使用一組「隱私權實務規則」的行事曆服務，以發表聲明和決定使用和披露個人資訊。 行事歷服務會結合隱私權實務規則與隱私權喜好設定來決定是否允許建議的使用或披露。

Web 用戶端

假設我們有一個 Web 用戶端與仲介層 Web 應用程式通訊，而仲介層 Web 應用程式則會在另一個網域中與 Web 服務通訊（安全地） 。 仲介層 Web 應用程式，這是 Web 服務感知，想要取得 Web 用戶端的安全性令牌。

此外，此案例假設安全性令牌可讓仲介層應用程式在與服務交談時代表用戶端採取行動。

若要啟用此案例，Web 用戶端的瀏覽器會存取仲介層應用程式，並重新導向至相關聯的身分識別服務。 驗證之後（例如，使用 HTML 窗體和 HTTPs），要求會重新導向回仲介層應用程式。 身分識別服務會將安全性令牌（判斷提示身分識別和委派）提供給原始仲介層應用程式 Web 伺服器（例如，使用透過 HTTPS 傳送的查詢字串）。 Web 伺服器現在可以使用這些安全性令牌，並將要求從自己的身分識別發出至 Web 服務。 Web 服務會處理要求，並將結果傳回至 Web 伺服器，其中結果會格式化並傳回至瀏覽器。

行動用戶端

上述檔中所述的規格提供大幅彈性，以解決行動安全性特有的設計挑戰。  Web 服務方法的彈性可支援多個密碼編譯技術，在具有有限計算和儲存功能的裝置上提供強式和高效能的密碼編譯保護。  同樣地，它可讓網路操作員提供安全性 Proxy，例如網路閘道，代表行動用戶端採取行動。 

以下是結合這兩個想法的範例。  當網路操作員支援行動用戶端（使用這些 Web 服務安全性規格）時，他們可以設定這些用戶端透過網路操作員的閘道傳送要求。  在此案例中，網關是主動參與整體訊息流程的SOAP媒介;具體而言，網路操作員正在提供專為行動裝置設計的加值加密演算法。  閘道可以增強或變更訊息的安全性令牌和保護品質。  請注意，此 Web 服務安全性模型中固有的彈性可讓此解決方案，即使裝置在外部網路上漫遊也一樣。 

以下範例說明這點：

啟用同盟

Web 服務安全性模型是設計來支援同盟。 以下是身分識別同盟的簡單範例：

Alice at Adventure456 想要在 Business456 使用 Currency Web 服務。 貨幣服務只會處理具有 Business456 所簽發之安全性令牌的要求。 Alice 只有具有 Adventure456 所簽發之身分識別宣告（亦即身分識別安全性令牌）的安全性令牌。

在此案例中，如果 Business456 願意接受與 Adventure456 的安全性同盟，Alice 才能存取貨幣服務。

下列小節說明數種安全性同盟方法。

使用安全性令牌交換的同盟

在這種方法中，貨幣服務的原則指出它只接受 Business456 所簽發的安全性令牌。 因為原則會指出取得必要安全性令牌的位置，Alice 會將 Adventure456 安全性令牌呈現（並證明）到 Business456 安全性令牌服務，並接收 Business456 安全性令牌。 然後，她向貨幣服務提出要求（並證明）此安全性令牌。 下圖說明這一點：

在此方法中，Business456 安全性令牌服務已設定為接受 Adventure456 所發出身分識別宣告的安全性令牌

請注意，此範例與強制執行商務原則案例中的範例非常類似。 這示範 Web 服務安全性模型的彈性。

使用信任鏈結的同盟

在這種方法中，貨幣服務會接受具有任何安全性令牌的要求，但除非可以根據提供的安全性令牌（和證明）取得 Business456 安全性令牌，否則不會處理要求。

若要這樣做，貨幣服務會將原始要求轉送至 Business456 安全性令牌服務，以評估初始安全性令牌。 如果有效，它會背書要求，並可能包含 Business456 安全性令牌，讓 Alice 在後續要求上使用。 下圖說明這一點。

在此方法中，Business456 安全性令牌服務已設定為接受 Adventure456 所發出身分識別宣告的安全性令牌

使用安全性令牌交換的同盟 （PKIKerberos）

在這個方法中，Adventure456 已發行 Alice 公鑰安全性令牌，而 Currency 服務的原則表示它只接受其 KDC 中的 Kerberos 安全性令牌。

在貨幣服務原則的方向，Alice 向 Business456 的安全性令牌服務呈現（並證明）她的公鑰安全性令牌。 安全性令牌服務會封裝 Business456 的 KDC。 因此，它能夠驗證 Alice 的公鑰安全性令牌，併為 Currency 服務發出 Kerberos 安全性令牌。 下圖說明：

在此方法中，Business456 安全性令牌服務已設定為接受具有 Adventure456 所發出身分識別宣告的公鑰安全性令牌。

使用安全性令牌交換同盟 （KerberosSecurity Token Service）

在這個方法中，Adventure456 已發行 Alice a Kerberos 安全性令牌，而 Currency 服務的原則表示它只接受其本身安全性令牌服務所簽發的安全性令牌。

我們在此假設 Adventure456 和 Business456 的系統管理員已交換公鑰憑證，以同盟安全性。 我們進一步假設Alice只支援對稱密鑰技術。

根據 Currency Web 服務原則，Alice 必須取得安全性令牌，以用來存取 Business456 的安全性令牌服務。 由於Alice使用對稱密鑰安全性令牌，Alice 會先連絡其安全性令牌服務，以取得商務用安全性令牌服務的安全性令牌。 請注意，此安全性令牌將包含對稱密鑰 Sab，以 Business456 安全性令牌服務的公鑰編碼。

Alice 使用商務用安全性令牌服務的安全性令牌，要求貨幣服務的安全性令牌。 Business456 安全性令牌服務會為 Alice 提供對稱密鑰、Sac，以及貨幣服務的安全性令牌。

Alice 使用適用於 Currency 服務和相關聯對稱密鑰的安全性令牌，對 Currency 服務提出要求。

使用認證交換同盟 （KerberosKerberos）

在此方法中，Adventure456 已發行 Alice a Kerberos 安全性令牌，而 Currency 服務的原則表示它只接受封裝其 KDC 之本身安全性令牌服務所簽發的 Kerberos 安全性令牌。

在此，我們假設 Adventure456 和 Business456 的系統管理員不想建立跨領域可轉移信任，但願意交換公鑰憑證以同盟安全性。 此外，我們假設 Alice 和 Currency 服務都只支援對稱密鑰技術。

如同上一個範例，安全性令牌服務能夠將對稱密鑰安全性令牌提供給其信任網域內的服務。 因此，上述方法在此案例中可運作。

驗證服務

此 Web 服務安全性模型也支援要求者 外包 訊息和安全性令牌驗證處理的案例。 請注意，誤用這類服務可能會導致延展性問題。 也就是說，視實作而定，服務執行驗證服務可能更便宜或更昂貴。 Web 服務安全性模型支援任一方法，藉此啟用此案例。

在此案例中，我們已將驗證服務與安全性令牌服務區隔開。 在其他情況下，它們可以合併或有直接信任關係（因此不需要 WS-Federation）。

在此案例中，要求者會從安全性令牌服務取得安全性令牌。 然後，它會將訊息傳送至 Web 服務，並包含擁有證明（例如簽章）。 Web 服務會傳送簽章區塊、安全性令牌，以及其已簽署至驗證服務的摘要計算。 Web 服務信任的驗證服務，然後發出有效/無效的決策。

請注意，驗證服務可以代表判斷提示適當宣告的要求者發出安全性令牌來指出其決策。

支援委派

Web 服務安全性支援委派。 以下是一個複雜的委派案例，旨在顯示方法的彈性：Alice 使用 calendar456 來管理她的排程。 她想讓鮑勃在週二與她會面。 不過，Bob 不會直接執行排程。 相反地，Bob 會使用排程 456 的服務來設定需要放在 Alice 行事曆上的會議。

Alice 不知道 Bob 如何排程會議，但她想要限制可以看到行事曆的服務集

Alice 提供 Bob 的安全性令牌，可讓 Bob 在行事曆上排程會議。 此安全性令牌包含限制 Bob 將會議排程到星期二的宣告。 此外，此安全性令牌可讓 Bob 發出後續的安全性令牌，只要主體能夠證明其具有來自 TrustUs456 的第三方服務的隱私權認證。

由於 TrustUs456 已稽核服務 Schedule456，因此其安全性令牌會判斷提示其隱私權認證。

當排程服務在 Calendar456 存取 Alice 的行事歷時，可以證明其隱私權認證擁有證明，以及根據 Alice 透過 Bob 本身的安全性令牌來存取和排程會議的要求。

存取控制

在一起工作時，Alice 和 Bob 發現他們經常彼此排程會議，並開發信任層級。 因此，Alice 希望允許 Bob 排程會議，而不需要每次都委派給他。 她可能會增加委派安全性令牌的到期時間，但她需要重新發行這些令牌，如果她想撤銷Bob排程會議的能力，這是有問題的。

Alice 會與行事曆服務通訊（驗證自己），並取得授權清單。 她會更新授權清單，讓 Bob 查看她的空閒/忙碌數據和排程會議，並將其提交至服務。 現在當 Bob 存取這些作業的行事曆服務時，他不需要 Alice 的委派安全性令牌。

審計

在上述委派案例中，對立者可能會嘗試在沒有委派安全性令牌或過期的安全性令牌的情況下排程會議。 在這種情況下，要求將會失敗，因為對立者無法證明必要的宣告。

為了追蹤這種類型的活動，服務可能會提供稽核功能。 也就是說，當安全性相關事件，例如驗證或未證明宣告或簽章錯誤時，就會記錄它。 系統管理員可以安全地存取記錄檔，以檢閱安全性相關事件及管理記錄。

例如，對立者可能會嘗試模仿Bob。 使用監視/管理工具時，安全性系統管理員 Carol 會檢閱稽核記錄，並看到 Alice 的行事曆發生許多安全性失敗。 在檢閱數據時，她看到鮑勃的要求有時失敗，因為他的簽章不符合訊息或訊息是舊的（重新執行）。 因此，Carol 收集稽核記錄，以用於試圖追蹤對抗者。

5 摘要

隨著 Web 服務更廣泛地套用，隨著應用程式拓撲持續演進，以支援防火牆、負載平衡器和傳訊中樞等媒介，以及隨著組織所面臨威脅的意識變得更清楚，Web 服務的額外安全性規格需求也會變得更清楚。  在本檔中，我們建議整合式 Web 服務安全性模型，以及一組實現該模型的規格。 這些新的規格，藉由擴充和利用現有的安全性技術和資產，可讓客戶和組織更快速地開發安全互通的 Web 服務。

IBM 和Microsoft認為，這是定義全面 Web 服務安全性策略的第一步。  它反映了我們迄今確定的挑戰和解決方案。 當我們繼續與客戶、合作夥伴和標準組織合作以保護 Web 服務時，我們預期需要額外的想法和規格，才能完成策略。 

貢獻

這份檔由IBM和 Microsoft 共同撰寫。

關鍵貢獻包括（字母順序）：喬瓦尼·德拉-利貝拉，Microsoft：布蘭登·迪克森，Microsoft：喬爾·法雷爾，IBM;普拉裡特·加格，Microsoft;瑪麗安·霍多，IBM;克裡斯·卡勒，Microsoft;巴特勒·普隆森，Microsoft：凱爾文·勞倫斯，IBM：安德魯·萊曼，Microsoft;保羅·利奇，Microsoft：約翰·曼弗德利，Microsoft;IBM馬魯山一郎;安東尼·納達林，IBM;納塔拉傑·納加拉特南，IBM;里克·拉希德，Microsoft：約翰·謝丘克，Microsoft：丹·西蒙，Microsoft;阿賈穆·韋斯利，IBM

引用