随着 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密钥管理服务(XML Key Management Services，简称XKMS)的备忘录，帮助分发及管理在端点之间进行安全通信所需的密钥。
端点验证及授权
1)支持在企业之间交换信息的合同中定义哪些雇员可以使用哪些服务。中介体负责审计和服务原始性证明。
2)支持网络内部的、可信任的第三方验证服务，例如Kerberos。
安全性服务描述
1)描述是否支持数字签名、加密、验证和授权以及如何支持它们。Web服务请求者使用服务描述的安全性元素，来查找符合政策要求及其安全性方法的服务端点。
2)OASIS成立了一个技术委员会来定义授权和验证断言(Authorization and Authentication Assertions，简称SAML)，帮助端点接受和决断访问控制权。
3)OASIS同时成立了另一个技术委员会来标准化访问控制权的表达 (eXtensible Access Control Markup Language，简称XACML)，帮助端点能够以一致的方式解析SAML断言。
XML相关标准化团体"Organization for the Advancement of StrUCtured Information Standards（OASIS）"的加盟企业成立了制定Web服务安全标准"Web Services Security（WS-Security）"的技术委员会"Web Services Security Technical Committee（WS-Security TC）"。这是OASIS于美国当地时间2002年7月23日宣布的。
WS-Security标准的目的是确保Web服务应用软件处理数据的完整性及保密性，规定了Web服务协议SOAP的扩展及消息头（Message Header）。这是由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] [2] [3]
1、WS-Security及有关的规范
下面介绍一个能够满足真实企业的Web服务安全性需要的基于标准的体系架构。IBM、Microsoft和Verisign联手制定了有关Web服务安全性的计划和指南，用来开发一组提供保护Web服务安全性的规范。这个安全性模型把不同的安全性技术，比如公用密钥基础架构、Kerberos等集中在一起，以保证能够在现有的系统环境中构建安全的Web服务。通过利用Web服务模型核心处的自然可扩展性，这些规范建立在一些基础技术的基础之上，如SOAP、WSDL、XML数字签名(XML Digital Signature)、XML加密(XML Encryption)和SSL技术。这允许Web服务提供者和请求者开发满足他们应用程序的个别安全性需求的解决方案。这是一个由IBM、Microsoft和Verisign提议的WS-Security规范定义，用于保护消息完整性和机密性的核心工具，以及用于把有关安全性的声明与消息关联起来的机制。
目前，SSL、Transport Layer Security(TLS)和IPSec被用于为Web服务应用程序提供传输级别的安全性。它们的安全性功能包括认证、数据完整性和数据机密性，保证点对点Web服务安全性。Web服务应用程序是个多跳(Multi-Hop)拓扑，依赖于消息处理中介体转发消息。当传输层之外的中介体接收并转发数据时，数据的完整性和任何随数据流动的安全性信息都可能失去。所以，全面的Web服务安全性体系架构必须是一个提供端到端安全性的机制。
图1所示为提议的Web服务安全性规范组合。
screen.width-300)this.width=screen.width-300' border='0' alt='Click to Open in New Window'>
图1 WEB 服务安全性规范组合
这组规范建立在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和其他规范集成来提供跨多个中介体和传输协议的端到端完整性和机密性。Public Key Infrastructure(PKI)模型涉及到签发带公用对称密钥的证书的证书机构和声明除密钥所有权之外属性的机构。这种证书的拥有者可以使用相关的密钥来表示多种声明。另外，Kerberos模型依靠与密钥分发中心(Key Distribution Center)通信，通过签发加密的对称密钥来代理各方之间的信任。Web服务安全性模型支持安全性令牌服务使用公用不对称密钥签发安全性令牌。现有的信任模型通常都是基于企业间的协定，例如UDDI商业注册中心的Web服务。UDDI有多个参与者，它的信任模型不是根据特定认证机制的要求为信任定义一个单独的模型，而是把认证的责任交给每个节点的信息管理员。每个UDDI中的Web服务可能有自己的认证机制并强制遵守自己的访问控制策略，而信任取决于服务请求者和管理其信息的操作员之间的信任。
[1] [2] [3]
2、Web服务可靠性及SOAP层安全扩展
由富士通、日立、NEC、Oracle、Sonic软件和Sun等领先IT厂商宣布，它们将合作发布Web服务可靠性(Web Services Reliability)技术规范工作草案。这一WS-Reliability技术规范将通过提供一个更为可靠的传输基础设施，加快Web服务的采用，以适应企业界各种各样的应用需求。
WS-Reliability是一个针对开放的、可靠的Web服务讯息递交的技术规范，包括担保递交、复制讯息排除和讯息分类等，使各种Web服务之间得以进行更可靠的讯息传递。WS-Reliability基于SOAP协议，而不局限于基础传输协议。
自从SOAP规范从2001年发布以来，SOAP规范的加密性，认证和授权等安全机制一直受到人们的广泛关注。这三个方面对于任何的B2B来说都是很重要的 ，但SOAP标准在制定规范时并没有过多考虑SOAP 的安全性要求。因为SOAP一个很重要的设计目标就在于它的简单性，尽可能的利用已有的标准和协议来实现相应的功能。
SOAP安全的解决方案基于三个W3C的XML规范来实现：XML Digital Signature, XML encryption, and XML Key Management Services。SOAP层安全处于传输层和应用层之上，对SOAP层的安全性进行扩展，把关于安全的五个基本要求应用到整个的SOAP信息中，包括SOAP头以及SOAP体。同时，更多的安全措施也可结合SOAP层安全与传输层以及应用程序来共同解决。（如下图2）
screen.width-300)this.width=screen.width-300' border='0' alt='Click to Open in New Window'>
图2 SOAP层安全扩展
1）SOAP 安全扩展: 数字签名 （Signature）
"SOAP Security Extensions: Digital Signature"最初设想是利用XML的数字签名（XML Digital Signature syntax [XML-Signature]）对SOAP进行扩展，在SOAP的头元素中定义签名属性（）来实现。
2）安全性令牌（Security Token） -定义安全性令牌表示与安全性相关的信息（例如，X.509 证书、Kerberos 票据和认证者、来自 SIM 卡的移动设备安全性令牌、用户名等等）。
SOAP规范在SOAP 1.1的头元素里定义了XML Signature 的使用，数字签名经过加密算法计算后的值附加在数据对象后面，数据接受对象从签名中可以验证数据的来源和完整性。加密后的传送信息可避免数据接受者受到伪造信息的蒙骗。虽然数字签名了提供这些安全服务:信息源的证明--信息的接受者可以确定这条信息的发出者的身份；信息的完整性---信息的接受者可以确定这条信息发出后没有被纂改；不可抵赖性---事物中的任何一方事后都不能否认他的行为。但是：数字签名没有提供信息认证，恶意破坏者可以记录一个信息并反复发送（重复攻击），为了避免受这种类型的攻击，数字签名必须结合一定的方法来保证信息的唯一性，如：时间戳（time stamps）或nonces 等。签名的日期和时间都附加在消息上,并与消息一起签名。添加这些信息可以在中加入扩展元素实现。当数字签名用来验证发送方的标识时，发送者必须提供一个私有秘钥等等。SOAP信息也可以使用其他安全技术，更多的SOAP安全规范正在不断的完善之中，随着SOAP安全性的增强，SOAP技术会得到越来越广泛的应用。
3) UDDI安全：识别与授权
使用UDDI的发布API的关键原则是只允许被授权的用户进行发布或修改UDDI商业注册中心中的数据。每一个分布式的UDDI商业注册中心维护-张唯-的授权用户列表，并跟踪所有用户创建的businessEntity或tModel数据。只有信息的创建者才允许对该信息进行更改或删除。
每个UDDI商业注册中心的实例被称为一个操作入口站点(Operator Site)，操作入口站点被允许定义他自己的用户授权机制，不过所有的签署协议的公共的UDDI注册中心操作入口站点都需要满足规定协议中定义的最小安全规范以提供类似的安全机制。
（出处：http://www.sheup.com）
[1] [2] [3]
3) UDDI安全：识别与授权
使用UDDI的发布API的关键原则是只允许被授权的用户进行发布或修改UDDI商业注册中心中的数据。每一个分布式的UDDI商业注册中心维护-张唯-的授权用户列表，并跟踪所有用户创建的businessEntity或tModel数据。只有信息的创建者才允许对该信息进行更改或删除。
每个UDDI商业注册中心的实例被称为一个操作入口站点(Operator Site)，操作入口站点被允许定义他自己的用户授权机制，不过所有的签署协议的公共的UDDI注册中心操作入口站点都需要满足规定协议中定义的最小安全规范以提供类似的安全机制。
（出处：http://www.sheup.com）
[1] [2] [3] [4]
SOAP规范在SOAP 1.1的头元素里定义了XML Signature 的使用，数字签名经过加密算法计算后的值附加在数据对象后面，数据接受对象从签名中可以验证数据的来源和完整性。加密后的传送信息可避免数据接受者受到伪造信息的蒙骗。虽然数字签名了提供这些安全服务:信息源的证明--信息的接受者可以确定这条信息的发出者的身份；信息的完整性---信息的接受者可以确定这条信息发出后没有被纂改；不可抵赖性---事物中的任何一方事后都不能否认他的行为。但是：数字签名没有提供信息认证，恶意破坏者可以记录一个信息并反复发送（重复攻击），为了避免受这种类型的攻击，数字签名必须结合一定的方法来保证信息的唯一性，如：时间戳（time stamps）或nonces 等。签名的日期和时间都附加在消息上,并与消息一起签名。添加这些信息可以在中加入扩展元素实现。当数字签名用来验证发送方的标识时，发送者必须提供一个私有秘钥等等。SOAP信息也可以使用其他安全技术，更多的SOAP安全规范正在不断的完善之中，随着SOAP安全性的增强，SOAP技术会得到越来越广泛的应用。
3) UDDI安全：识别与授权
使用UDDI的发布API的关键原则是只允许被授权的用户进行发布或修改UDDI商业注册中心中的数据。每一个分布式的UDDI商业注册中心维护-张唯-的授权用户列表，并跟踪所有用户创建的businessEntity或tModel数据。只有信息的创建者才允许对该信息进行更改或删除。
每个UDDI商业注册中心的实例被称为一个操作入口站点(Operator Site)，操作入口站点被允许定义他自己的用户授权机制，不过所有的签署协议的公共的UDDI注册中心操作入口站点都需要满足规定协议中定义的最小安全规范以提供类似的安全机制。
（出处：http://www.sheup.com）
[1] [2] [3] [4] [5]