隨著Web服務由技術概念到實踐應用的不斷發展，種種跡象表明Web服務將是未來應用架構的一個極為重要的模式。當Web服務用於試驗計劃和大規模生產時，擁有一種松散耦合的、與語言和平台無關的、在組織內跨企業、跨因特網鏈接應用程序的方法的好處正變得愈發明顯。我們的客戶、業界分析家和新聞界確定了當Web服務日益成為主流時要解決的關鍵問題：安全性。這篇文章就是討論如何選擇並實現基於標准的安全體系架構，滿足真實企業的Web服務安全需要。
Web服務體系架構的關鍵是能夠交付集成的、可互操作的解決方案。通過應用這個安全模型，確保Web服務的完整性、機密性和安全性，這對軟件商和它們的客戶來說都至關重要。將會出台的Web服務基本的安全規范包括：
用於整合的Web服務描述語言、用於認證和授權的安全性聲明標記語言、用於渠道保密的安全槽層（SSL）、用於高度機密的XML加密標准和用於高級授權的XML數字簽名。此外，其他幾項規范也會陸續出台，包括：
Web服務安全性規范（包括XML-加密和XML-數字簽名）、XML密鑰管理規范和用於授權的可擴展訪問控制標記語言規范等等。
為Web服務提供安全功能和組件的模型需要把現有的流程和技術與將來的應用程序的安全性需求集成起來。統一的安全技術就必須把應用程序對安全的需求從特定的機制中抽象出來。目的是讓開發者能夠容易地使用異類系統建立可互操作的安全解決方案。成功的Web服務安全方法需要一組靈活的、可互操作的基本元素，通過策略和配置，這些安全性基本元素可以使多種安全解決方案成為可行的方案。可行的Web服務安全性機制需要滿足和包括下列組件的要求：
網絡安全性
支持如SSL等提供機密性和完整性的安全傳輸機制。
XML消息安全性
1)XML數字簽名，以便接收方可以證明消息發送方的身份。
2)XML加密，提供數據元素的機密性使能夠驗證交換。W3C發布XML密鑰管理服務(XMLKeyManagementServices，簡稱XKMS)的備忘錄，幫助分發及管理在端點之間進行安全通信所需的密鑰。
端點驗證及授權
1)支持在企業之間交換信息的合同中定義哪些雇員可以使用哪些服務。中介體負責審計和服務原始性證明。
2)支持網絡內部的、可信任的第三方驗證服務，例如Kerberos。
安全性服務描述
1)描述是否支持數字簽名、加密、驗證和授權以及如何支持它們。Web服務請求者使用服務描述的安全性元素，來查找符合政策要求及其安全性方法的服務端點。
2)OASIS成立了一個技術委員會來定義授權和驗證斷言(AuthorizationandAuthenticationAssertions，簡稱SAML)，幫助端點接受和決斷訪問控制權。
3)OASIS同時成立了另一個技術委員會來標准化訪問控制權的表達(eXtensibleAccessControlMarkupLanguage，簡稱XACML)，幫助端點能夠以一致的方式解析SAML斷言。
XML相關標准化團體"OrganizationfortheAdvancementofStructuredInformationStandards（OASIS）"的加盟企業成立了制定Web服務安全標准"WebServicesSecurity（WS-Security）"的技術委員會"WebServicesSecurityTechnicalCommittee（WS-SecurityTC）"。這是OASIS於美國當地時間2002年7月23日宣布的。
WS-Security標准的目的是確保Web服務應用軟件處理數據的完整性及保密性，規定了Web服務協議SOAP的擴展及消息頭（MessageHeader）。這是由IBM、微軟和VeriSign共同研究制定的。WS-Security融合了多種安全模式、結構和技術，是面向Web服務的標准規格之一。各種系統可以通過平台及不依賴語言的方法確保相互兼容。
WS-Security描述通過消息完整性、消息機密性和單獨消息認證提供保護質量對SOAP消息傳遞的增強。這些機制可以用於提供多種安全性模型和加密技術。WS-Security還提供關聯安全性令牌和消息的通用機制。WS-Security不需要特定類型的安全性令牌。它在設計上就是可擴展的（例如支持多安全性令牌格式）。舉例來說，客戶機可能會提供身份證明和他們有特定商業認證的證明。
另外，WS-Security還描述如何對二進制安全性令牌編碼。此規范特別描述如何對X.509證書和Kerberos票據編碼以及如何加入難於理解的加密密鑰。它還包括可以用於進一步描述消息中包含的憑證特征的擴展性機制。
WS-Security很靈活，它被設計成用來構建多種安全性模型（包括PKI、Kerberos和SSL）的基礎。WS-Security特別為多安全性令牌、多信任域、多簽名格式和多加密技術提供支持。規范提供了三種主要的機制：安全性令牌傳播、消息完整性和消息機密性。這些機制本身並不提供完整的安全性解決方案。相反，WS-Security是一種構件，它可以與其它Web服務擴展和更高級的特定於應用程序的協議聯合使用，以適應多種安全性模型和加密技術。這些機制可以獨立使用（例如傳送安全性令牌），或以緊密集成的方式使用（例如，對消息簽名和加密，並提供與用於簽名和加密的密鑰相關的安全性令牌層次結構）。
1、WS-Security及有關的規范
下面介紹一個能夠滿足真實企業的Web服務安全性需要的基於標准的體系架構。IBM、Microsoft和Verisign聯手制定了有關Web服務安全性的計劃和指南，用來開發一組提供保護Web服務安全性的規范。這個安全性模型把不同的安全性技術，比如公用密鑰基礎架構、Kerberos等集中在一起，以保證能夠在現有的系統環境中構建安全的Web服務。通過利用Web服務模型核心處的自然可擴展性，這些規范建立在一些基礎技術的基礎之上，如SOAP、WSDL、XML數字簽名(XMLDigitalSignature)、XML加密(XMLEncryption)和SSL技術。這允許Web服務提供者和請求者開發滿足他們應用程序的個別安全性需求的解決方案。這是一個由IBM、Microsoft和Verisign提議的WS-Security規范定義，用於保護消息完整性和機密性的核心工具，以及用於把有關安全性的聲明與消息關聯起來的機制。
目前，SSL、TransportLayerSecurity(TLS)和IPSec被用於為Web服務應用程序提供傳輸級別的安全性。它們的安全性功能包括認證、數據完整性和數據機密性，保證點對點Web服務安全性。Web服務應用程序是個多跳(Multi-Hop)拓撲，依賴於消息處理中介體轉發消息。當傳輸層之外的中介體接收並轉發數據時，數據的完整性和任何隨數據流動的安全性信息都可能失去。所以，全面的Web服務安全性體系架構必須是一個提供端到端安全性的機制。
圖1所示為提議的Web服務安全性規范組合。
圖1WEB服務安全性規范組合
這組規范建立在SOAP標准規范上，包括一個WS-Security的消息安全性模型、一個描述Web服務端點策略的WS-Policy、一個WS-Trust信任模型和一個隱私權模型WS-Privacy。在這些規范的基礎上，可以跨多個信任域創建安全的、可互操作的Web服務，還可以提供後繼規范，例如安全會話WS-SecureConversation、聯合信任WS-Federation和授權WS-Authorization。安全性規范、相關活動和互操作性概要文件組合在一起，將方便開發者建立可互操作的、安全的Web服務。下面簡單描述被提議的各個規范：
WS-Security
描述如何向SOAP消息附加簽名和加密報頭，還描述如何向消息附加安全性令牌，比如二進制安全性令牌的X.509證書和Kerberos票據。提供了一個通用機制把可擴展的安全性令牌與消息關聯起來。使用XML簽名和安全性令牌可以確保消息的完整性，消息在傳輸過程中未被修改。同樣地，使用XML加密和安全性令牌可以使SOAP消息的一部分保密，提供消息機密性。
WS-Policy
描述中介體和端點上的安全性策略的能力和限制，比如所需的安全性令牌、所支持的加密算法和隱私權規則。這是可擴展的，並且不會對可以描述的要求和能力的類型做什麼限制，此規范識別幾個基本的服務屬性，包括隱私權屬性、編碼格式、安全性令牌要求和支持的算法。
WS-Trust
描述使Web服務能夠安全地進行互操作的信任模型的框架。此規范描述如何通過創建安全性令牌保證服務把現有的直接信任關系用作代理信任的基礎。
這些安全性令牌保證服務建立在WS-Security的基礎上，用一種保證令牌的完整性和機密性的方式傳送那些必需的安全性令牌。
WS-Privacy
描述Web服務提供者和請求者如何聲明主題隱私權首選項和組織隱私權實踐聲明的模型。通過使用WS-Policy、WS-Security和WS-Trust的組合，商業機構可以聲明並指出遵守聲明的隱私權策略。此規范描述一個關於如何把隱私權語言嵌入到WS-Policy的描述，以及如何使用WS-Security把隱私權聲明與消息關聯起來的模型，它還描述如何使用WS-Trust機制，同時為用戶首選項和組織實踐聲明評價這些隱私權聲明。
WS-SecureConversation
描述如何管理和認證各方之間的消息交換，包括安全性上下文交換以及建立和派生會話密鑰。
WS-Federation
描述如何管理和代理異類聯合的環境中的信任關系，包括支持聯合身份。此規范定義如何使用WS-Security、WS-Policy、WS-Trust和WS-SecureConversation規范構建聯合信任案例，例如如何把Kerberos和PKI基礎架構聯合起來。
WS-Authorization
描述如何管理授權數據和授權策略，如何在安全性令牌內指定聲明，以及這些聲明在端點處將如何被解釋。此規范在授權格式和授權語言上是靈活且可擴展的。
由於這個Web服務安全性模型與現今普遍使用的用於認證、數據完整性和數據機密性的現有安全性模型兼容，所以它可以把基於Web服務的解決方案與現有的其他安全性模型集成起來。例如，現有技術如SSL為消息提供簡單的點對點完整性和機密性，而Web服務安全性模型支持把這些現有的安全傳輸機制與WS-Security和其他規范集成來提供跨多個中介體和傳輸協議的端到端完整性和機密性。PublicKeyInfrastructure(PKI)模型涉及到簽發帶公用對稱密鑰的證書的證書機構和聲明除密鑰所有權之外屬性的機構。這種證書的擁有者可以使用相關的密鑰來表示多種聲明。另外，Kerberos模型依靠與密鑰分發中心(KeyDistributionCenter)通信，通過簽發加密的對稱密鑰來代理各方之間的信任。Web服務安全性模型支持安全性令牌服務使用公用不對稱密鑰簽發安全性令牌。現有的信任模型通常都是基於企業間的協定，例如UDDI商業注冊中心的Web服務。UDDI有多個參與者，它的信任模型不是根據特定認證機制的要求為信任定義一個單獨的模型，而是把認證的責任交給每個節點的信息管理員。每個UDDI中的Web服務可能有自己的認證機制並強制遵守自己的訪問控制策略，而信任取決於服務請求者和管理其信息的操作員之間的信任。
2、Web服務可靠性及SOAP層安全擴展
由富士通、日立、NEC、Oracle、Sonic軟件和Sun等領先IT廠商宣布，它們將合作發布Web服務可靠性(WebServicesReliability)技術規范工作草案。這一WS-Reliability技術規范將通過提供一個更為可靠的傳輸基礎設施，加快Web服務的采用，以適應企業界各種各樣的應用需求。
WS-Reliability是一個針對開放的、可靠的Web服務訊息遞交的技術規范，包括擔保遞交、復制訊息排除和訊息分類等，使各種Web服務之間得以進行更可靠的訊息傳遞。WS-Reliability基於SOAP協議，而不局限於基礎傳輸協議。
自從SOAP規范從2001年發布以來，SOAP規范的加密性，認證和授權等安全機制一直受到人們的廣泛關注。這三個方面對於任何的B2B來說都是很重要的，但SOAP標准在制定規范時並沒有過多考慮SOAP的安全性要求。因為SOAP一個很重要的設計目標就在於它的簡單性，盡可能的利用已有的標准和協議來實現相應的功能。
SOAP安全的解決方案基於三個W3C的XML規范來實現：XMLDigitalSignature,XMLencryption,andXMLKeyManagementServices。SOAP層安全處於傳輸層和應用層之上，對SOAP層的安全性進行擴展，把關於安全的五個基本要求應用到整個的SOAP信息中，包括SOAP頭以及SOAP體。同時，更多的安全措施也可結合SOAP層安全與傳輸層以及應用程序來共同解決。（如下圖2）
圖2SOAP層安全擴展
1）SOAP安全擴展:數字簽名（Signature）
"SOAPSecurityExtensions:DigitalSignature"最初設想是利用XML的數字簽名（XMLDigitalSignaturesyntax[XML-Signature]）對SOAP進行擴展，在SOAP的頭元素中定義簽名屬性（<SOAP-SEC:Signature>）來實現。
2）安全性令牌（SecurityToken）-定義安全性令牌表示與安全性相關的信息（例如，X.509證書、Kerberos票據和認證者、來自SIM卡的移動設備安全性令牌、用戶名等等）。
SOAP規范在SOAP1.1的頭元素裡定義了XMLSignature的使用，數字簽名經過加密算法計算後的值附加在數據對象後面，數據接受對象從簽名中可以驗證數據的來源和完整性。加密後的傳送信息可避免數據接受者受到偽造信息的蒙騙。雖然數字簽名了提供這些安全服務:信息源的證明--信息的接受者可以確定這條信息的發出者的身份；信息的完整性---信息的接受者可以確定這條信息發出後沒有被纂改；不可抵賴性---事物中的任何一方事後都不能否認他的行為。但是：數字簽名沒有提供信息認證，惡意破壞者可以記錄一個信息並反復發送（重復攻擊），為了避免受這種類型的攻擊，數字簽名必須結合一定的方法來保證信息的唯一性，如：時間戳（timestamps）或nonces等。簽名的日期和時間都附加在消息上,並與消息一起簽名。添加這些信息可以在中加入擴展元素實現。當數字簽名用來驗證發送方的標識時，發送者必須提供一個私有秘鑰等等。SOAP信息也可以使用其他安全技術，更多的SOAP安全規范正在不斷的完善之中，隨著SOAP安全性的增強，SOAP技術會得到越來越廣泛的應用。
3)UDDI安全：識別與授權
使用UDDI的發布API的關鍵原則是只允許被授權的用戶進行發布或修改UDDI商業注冊中心中的數據。每一個分布式的UDDI商業注冊中心維護-張唯-的授權用戶列表，並跟蹤所有用戶創建的businessEntity或tModel數據。只有信息的創建者才允許對該信息進行更改或刪除。
每個UDDI商業注冊中心的實例被稱為一個操作入口站點(OperatorSite)，操作入口站點被允許定義他自己的用戶授權機制，不過所有的簽署協議的公共的UDDI注冊中心操作入口站點都需要滿足規定協議中定義的最小安全規范以提供類似的安全機制。
