论文部分内容阅读
摘要：本文首先描述Web Service在解决安全问题上的现有方案的不足，在此基础上引入了WS-Security规范，并对此从完整性、机密性、认证这三个主要方面进行了详细的描述，最后简要介绍了在SOAP中如何将以上几方面进行综合。
关键字：WS-Security；Web Service；XML Signature；XML Encryption
中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)04-10964-03
1 引言
随着Web Service由技术概念到实践应用的不断发展，种种迹象表明Web Service将是未来应用架构的一个极为重要的模式。Web Service的一个重要的特征就是松耦合。服务的可发现性，平台无关性，接口的自描述性构成了Web Service的这一重要特点。而正是由于这个特点，Web Service被广泛的用于企业信息集成，其中既包括了企业内部的信息集成，也包括了企业与企业之间的信息集成。
在考虑企业应用的时候，一个不得不关注的问题就是安全。而Web Service的诸多优点反而使得安全问题变得比以往任何时候都更具挑战性。由于Web Service被广泛的运用于企业间的交互，使得安全边界由Intranet扩大到了Internet，安全的风险也自然大大增加；SOA中服务组合的思想，使得Web Service应用更具动态性，服务的创建者往往无法预料到服务将在何种环境下（比如使用何种安全认证方式）被使用，在这种情况下要想实现服务的安全访问变得更加复杂[2]。
2 Http下的解决方案
在没有运用WS-Security之前，主要是通过Https提供的运输层的安全来确保的运行在此之上Web Service的安全的。要想实现Web Service的安全，最重要的就是让服务请求方和服务提供方能够共享一个秘密（对称密钥）。有了对称密钥就可以用它加密，从而保证消息的机密性，也可以利用它来加密摘要从而保证消息的Integrity，并用于身份鉴别，这点从Kerberos和SSL协议中都可以看出。在Kerberos协议中，我们通过引入一个第三方(KDC)来实现密钥的发布。
目前Web Service广泛采用Https来保障安全，但是该方法也有很多的缺点，尤其是应用于现在越来越复杂的Web Service安全需求：
(1)Https提供的是点对点安全保护，而Web Service的特点就是消息往往就要经过多个中介才能到达最终的服务提供方，每个中介还有可能对消息做出些处理，也就是说它需要的是端到端的保护。
(2)Https是在传输层提供的安全，而不是在消息层面，也就是只有在传输的过程中消息才是安全的（加密的），而一旦到达了终点就是明文的了。
(3)在Https建立完共享密钥后，传递消息的时候并没有使用数字签名技术，所以也就无法得到抗否认性的能力。
(4)由于Https提供的是传输层的安全，当然也就不可能达到消息安全所需要的灵活性的要求。
(5)以Https作为其传输层，常常依赖于Http原有的安全机制（如SSL）。但是Web Service在未来的实现中还将引入其它的传输方式，如SMTP、TCP、FTP，消息队列等，而HTTP的安全机制并不一定适用[2]。
3 WS-Security
WS-Security标准的目的是确保Web Service应用软件处理数据的完整性及保密性，规定了Web Service协议SOAP的扩展及消息头（Message Header）。WS-Security融合了多种安全模式、结构和技术，是面向Web Service的标准规格之一。各种系统可以通过平台及不依赖语言的方法确保相互兼容。
WS-Security描述通过消息完整性、消息机密性和单独消息认证提供对SOAP消息传递的保护。这些机制可以用于提供多种安全性模型和加密技术。WS-Security 还提供关联安全
性令牌和消息的通用机制，不需要特定类型的安全性令牌，它在设计上是可扩展的。
WS-Security很灵活，它被设计成用来构建多种安全性模型（包括 PKI、Kerberos和SSL）的基础。WS-Security特别为多安全性令牌、多信任域、多签名格式和多加密技术提供支持。规范提供了三种主要的机制：安全性令牌传播、消息完整性和消息机密性。这些机制本身并不提供完整的安全性解决方案。相反，WS-Security 是一种构件，它可以与其它Web Service扩展和更高级的特定于应用程序的协议联合使用，以适应多种安全性模型和加密技术。这些机制可以独立使用或以紧密集成的方式使用。
3.1 完整性
XML Signature规范是将数字签名和XML组合而成的产物，不要以为XML Signature仅仅是将数字签名技术应用于XML文件。
下面对Signature中出现的各个元素做简要介绍：
SignedInfo表示最终要被签名的对象，签名主要包括两个过程，先对要签名的对象做摘要，然后加密摘要。
CanonicalizationMethod代表了将XML元素标准化的方法。
SignatureMethod指定了用于签名的方法，其中包括了摘要所用的方法以及是使用非对称密钥还是对称密钥加密(或混合)。
Reference表示真正想要签名的对象，通过URI定位到要签名的对象，如果没有指定URI就表示要签名的整个XML文件。
Transforms表示了在签名前可能对被签名对象所要做的转换。
DigestMethod指定了对引用对象做摘要的方法，一般使用SHA1。
DigestValue这里面存放做完摘要后的结果，这样当后面对做SignedInfo签名的时候就间接的对引用对象做了签名，从而保证其完整性。
SignatureValue这里存放的是对SignedInfo元素标准化后签名的结果。
KeyInfo是一个可选项，它用于消息接受方查找验证签名时所需的密钥。
Object用于定义一些扩展信息，也是可选项。
3.2 机密性
虽然签名可以保证消息在传送的途中没有被篡改，但是并不能避免它被偷取。如果消息没有经过加密，那么某个敏感的信息就会被泄漏。与XML Signature类似，结合了XML技术和传统加密技术而产生的XML Encryption，也并不仅仅是加密XML文件那么简单，它提供了以下的功能：
(1)加密整个XML文件；
(2)加密XML文件中的某个元素；
(3)加密XML文件中某个元素的内容；
(4)加密非XML格式的资源。(例如一张JPEG图片)；
(5)加密已经过加密的内容。
XML Encryption的结构如下所示：
(x)? 代表x出现0-1次(x)+ 代表x出现1-n次(x)* 代表x出现0-n次
与XML Signature不同，XML Encryption更加体现了自包含的性质，它不象XML Signature通过引用对某个资源签名，而是在原资源的位置上创建一个新的EncryptedData元素完全的替代原资源(使用CipherReference除外)。也是因为这个原因，你不可能象XML Signature那样在一个Signature元素中对多个资源签名，有几个需要加密的资源就有几个EncryptedData元素替代它们。
EncryptedData元素是原资源经过XML Encryption作用后的结果，将替代原资源。
EncryptionMethod元素指定加密将使用的算法。
CipherData元素中的内容为原资源加密后的结果。
EncryptionProperties元素用于为加密的数据添加一些额外的信息。
KeyInfo元素描述加密所使用的密钥。在签名的时候，大多使用非对称密钥，即利用私钥产生签名，然后将公钥信息放在KeyInfo元素中，这样消息的接受方就可以直接使用公钥来验证签名。
3.3 认证
认证即是消息发送者将证明自己身份的安全令牌传递给接收者。安全令牌(SecurityToken)代表Web Service请求者的身份，通过和数字签名技术结合，服务提供者可以确认SOAP消息由合法的服务请求者产生。
WS-Security 定义了三种安全元素(Security Element) 来传递各种安全令牌。
(1)< UsernameToken >该元素用来传递简单的用户名和密码给接收者。
由于XML文档并不能直接包含任意的二进制数据，所以二进制安全令牌必须经过编码才能包含在SOAP消息中。编码类型由属性“EncodingType”指定，标准预定义Base64 和十六进制数两种编码类型。安全令牌的类型由属性“ValueType”来指定，标准预定义X. 509 证书和Kerberos 票据（Ticket）两种安全令牌。
在前面两种传递方式中，安全令牌本身就包含在SOAP消息中。而这种方式则是指定一个外部URI，由接收者根据这个URI去获取相应的安全令牌。
3.4 WS-Security core
在分别介绍了XML Signature和XML Encryption后，我们了解了如何用XML的形式来保证消息的完整性(Integrity)和机密性(Confidentiality)。如何将其运用到Web Service中从而保证Web Service的安全性，这就是WS-Security规范所描述的内容。我们知道Web Service采用SOAP作为消息封装协议，因此WS-Security规范主要描述了如何将XML Security(XML Signature和XML Encryption)与已有的安全技术(Kerberos, X.509,SAML)结合, 并把它们绑定到SOAP中。
下面是一个典型的使用WS-Security协议来保证SOAP消息安全的例子。
从以上内容可以看出WS-Security协议主要对SOAP消息的Head部分做了扩展——加入了wsse:Security元素。其中针对安全的三个方面Authentication, Integrity, Confidentiality分别定义了Security Token, XML Signature以及XML Encryption Reference List三个子元素。而在SOAP包中的需要加密的业务内容(通常会加密整个Soap Body)被经过XML Encryption处理过的元素(EncryptedDate)所替代。
4 结论
当然，仅靠这些，并不能解决Web Service应用中所有的安全问题，WS-Security的价值在于提供了一层足够灵活的基础安全机制。基于这一机制，可以根据具体的Web Service应用环境，构筑更完善的安全模型。例如基于WS-Security开发的Web Service信托模型WS-Trust以及Web Service的安全联盟规范WS-Federation，为构建安全的跨越Internet，多企业合作的Web Service应用提供了坚实的安全基础。
参考文献：
[1]Web Services Security: SOAP Message Security 1.1(WS-Security 2004)[DB/OL].http://docs.oasis-open.org/wss/v1.1/2006-2-1.
[2]Web Service Security --- Introduction[DB/OL].http://idior.cnblogs.com/articles/353923.html 2006-2.
[3]石伟鹏,杨小虎.基于SOAP协议的Web Service安全基础规范[M].计算机应用研究,2003.
[4]王凡,李勇.基于WS-Security构筑安全的SOAP消息调用[M].计算机应用,2004-4.
本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。
关键字：WS-Security；Web Service；XML Signature；XML Encryption
中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)04-10964-03
1 引言
随着Web Service由技术概念到实践应用的不断发展，种种迹象表明Web Service将是未来应用架构的一个极为重要的模式。Web Service的一个重要的特征就是松耦合。服务的可发现性，平台无关性，接口的自描述性构成了Web Service的这一重要特点。而正是由于这个特点，Web Service被广泛的用于企业信息集成，其中既包括了企业内部的信息集成，也包括了企业与企业之间的信息集成。
在考虑企业应用的时候，一个不得不关注的问题就是安全。而Web Service的诸多优点反而使得安全问题变得比以往任何时候都更具挑战性。由于Web Service被广泛的运用于企业间的交互，使得安全边界由Intranet扩大到了Internet，安全的风险也自然大大增加；SOA中服务组合的思想，使得Web Service应用更具动态性，服务的创建者往往无法预料到服务将在何种环境下（比如使用何种安全认证方式）被使用，在这种情况下要想实现服务的安全访问变得更加复杂[2]。
2 Http下的解决方案
在没有运用WS-Security之前，主要是通过Https提供的运输层的安全来确保的运行在此之上Web Service的安全的。要想实现Web Service的安全，最重要的就是让服务请求方和服务提供方能够共享一个秘密（对称密钥）。有了对称密钥就可以用它加密，从而保证消息的机密性，也可以利用它来加密摘要从而保证消息的Integrity，并用于身份鉴别，这点从Kerberos和SSL协议中都可以看出。在Kerberos协议中，我们通过引入一个第三方(KDC)来实现密钥的发布。
目前Web Service广泛采用Https来保障安全，但是该方法也有很多的缺点，尤其是应用于现在越来越复杂的Web Service安全需求：
(1)Https提供的是点对点安全保护，而Web Service的特点就是消息往往就要经过多个中介才能到达最终的服务提供方，每个中介还有可能对消息做出些处理，也就是说它需要的是端到端的保护。
(2)Https是在传输层提供的安全，而不是在消息层面，也就是只有在传输的过程中消息才是安全的（加密的），而一旦到达了终点就是明文的了。
(3)在Https建立完共享密钥后，传递消息的时候并没有使用数字签名技术，所以也就无法得到抗否认性的能力。
(4)由于Https提供的是传输层的安全，当然也就不可能达到消息安全所需要的灵活性的要求。
(5)以Https作为其传输层，常常依赖于Http原有的安全机制（如SSL）。但是Web Service在未来的实现中还将引入其它的传输方式，如SMTP、TCP、FTP，消息队列等，而HTTP的安全机制并不一定适用[2]。
3 WS-Security
WS-Security标准的目的是确保Web Service应用软件处理数据的完整性及保密性，规定了Web Service协议SOAP的扩展及消息头（Message Header）。WS-Security融合了多种安全模式、结构和技术，是面向Web Service的标准规格之一。各种系统可以通过平台及不依赖语言的方法确保相互兼容。
WS-Security描述通过消息完整性、消息机密性和单独消息认证提供对SOAP消息传递的保护。这些机制可以用于提供多种安全性模型和加密技术。WS-Security 还提供关联安全
性令牌和消息的通用机制，不需要特定类型的安全性令牌，它在设计上是可扩展的。
WS-Security很灵活，它被设计成用来构建多种安全性模型（包括 PKI、Kerberos和SSL）的基础。WS-Security特别为多安全性令牌、多信任域、多签名格式和多加密技术提供支持。规范提供了三种主要的机制：安全性令牌传播、消息完整性和消息机密性。这些机制本身并不提供完整的安全性解决方案。相反，WS-Security 是一种构件，它可以与其它Web Service扩展和更高级的特定于应用程序的协议联合使用，以适应多种安全性模型和加密技术。这些机制可以独立使用或以紧密集成的方式使用。
3.1 完整性
XML Signature规范是将数字签名和XML组合而成的产物，不要以为XML Signature仅仅是将数字签名技术应用于XML文件。
下面对Signature中出现的各个元素做简要介绍：
SignedInfo表示最终要被签名的对象，签名主要包括两个过程，先对要签名的对象做摘要，然后加密摘要。
CanonicalizationMethod代表了将XML元素标准化的方法。
SignatureMethod指定了用于签名的方法，其中包括了摘要所用的方法以及是使用非对称密钥还是对称密钥加密(或混合)。
Reference表示真正想要签名的对象，通过URI定位到要签名的对象，如果没有指定URI就表示要签名的整个XML文件。
Transforms表示了在签名前可能对被签名对象所要做的转换。
DigestMethod指定了对引用对象做摘要的方法，一般使用SHA1。
DigestValue这里面存放做完摘要后的结果，这样当后面对做SignedInfo签名的时候就间接的对引用对象做了签名，从而保证其完整性。
SignatureValue这里存放的是对SignedInfo元素标准化后签名的结果。
KeyInfo是一个可选项，它用于消息接受方查找验证签名时所需的密钥。
Object用于定义一些扩展信息，也是可选项。
3.2 机密性
虽然签名可以保证消息在传送的途中没有被篡改，但是并不能避免它被偷取。如果消息没有经过加密，那么某个敏感的信息就会被泄漏。与XML Signature类似，结合了XML技术和传统加密技术而产生的XML Encryption，也并不仅仅是加密XML文件那么简单，它提供了以下的功能：
(1)加密整个XML文件；
(2)加密XML文件中的某个元素；
(3)加密XML文件中某个元素的内容；
(4)加密非XML格式的资源。(例如一张JPEG图片)；
(5)加密已经过加密的内容。
XML Encryption的结构如下所示：
(x)? 代表x出现0-1次(x)+ 代表x出现1-n次(x)* 代表x出现0-n次
与XML Signature不同，XML Encryption更加体现了自包含的性质，它不象XML Signature通过引用对某个资源签名，而是在原资源的位置上创建一个新的EncryptedData元素完全的替代原资源(使用CipherReference除外)。也是因为这个原因，你不可能象XML Signature那样在一个Signature元素中对多个资源签名，有几个需要加密的资源就有几个EncryptedData元素替代它们。
EncryptedData元素是原资源经过XML Encryption作用后的结果，将替代原资源。
EncryptionMethod元素指定加密将使用的算法。
CipherData元素中的内容为原资源加密后的结果。
EncryptionProperties元素用于为加密的数据添加一些额外的信息。
KeyInfo元素描述加密所使用的密钥。在签名的时候，大多使用非对称密钥，即利用私钥产生签名，然后将公钥信息放在KeyInfo元素中，这样消息的接受方就可以直接使用公钥来验证签名。
3.3 认证
认证即是消息发送者将证明自己身份的安全令牌传递给接收者。安全令牌(SecurityToken)代表Web Service请求者的身份，通过和数字签名技术结合，服务提供者可以确认SOAP消息由合法的服务请求者产生。
WS-Security 定义了三种安全元素(Security Element) 来传递各种安全令牌。
(1)< UsernameToken >该元素用来传递简单的用户名和密码给接收者。
由于XML文档并不能直接包含任意的二进制数据，所以二进制安全令牌必须经过编码才能包含在SOAP消息中。编码类型由属性“EncodingType”指定，标准预定义Base64 和十六进制数两种编码类型。安全令牌的类型由属性“ValueType”来指定，标准预定义X. 509 证书和Kerberos 票据（Ticket）两种安全令牌。
在前面两种传递方式中，安全令牌本身就包含在SOAP消息中。而这种方式则是指定一个外部URI，由接收者根据这个URI去获取相应的安全令牌。
3.4 WS-Security core
在分别介绍了XML Signature和XML Encryption后，我们了解了如何用XML的形式来保证消息的完整性(Integrity)和机密性(Confidentiality)。如何将其运用到Web Service中从而保证Web Service的安全性，这就是WS-Security规范所描述的内容。我们知道Web Service采用SOAP作为消息封装协议，因此WS-Security规范主要描述了如何将XML Security(XML Signature和XML Encryption)与已有的安全技术(Kerberos, X.509,SAML)结合, 并把它们绑定到SOAP中。
下面是一个典型的使用WS-Security协议来保证SOAP消息安全的例子。
从以上内容可以看出WS-Security协议主要对SOAP消息的Head部分做了扩展——加入了wsse:Security元素。其中针对安全的三个方面Authentication, Integrity, Confidentiality分别定义了Security Token, XML Signature以及XML Encryption Reference List三个子元素。而在SOAP包中的需要加密的业务内容(通常会加密整个Soap Body)被经过XML Encryption处理过的元素(EncryptedDate)所替代。
4 结论
当然，仅靠这些，并不能解决Web Service应用中所有的安全问题，WS-Security的价值在于提供了一层足够灵活的基础安全机制。基于这一机制，可以根据具体的Web Service应用环境，构筑更完善的安全模型。例如基于WS-Security开发的Web Service信托模型WS-Trust以及Web Service的安全联盟规范WS-Federation，为构建安全的跨越Internet，多企业合作的Web Service应用提供了坚实的安全基础。
参考文献：
[1]Web Services Security: SOAP Message Security 1.1(WS-Security 2004)[DB/OL].http://docs.oasis-open.org/wss/v1.1/2006-2-1.
[2]Web Service Security --- Introduction[DB/OL].http://idior.cnblogs.com/articles/353923.html 2006-2.
[3]石伟鹏,杨小虎.基于SOAP协议的Web Service安全基础规范[M].计算机应用研究,2003.
[4]王凡,李勇.基于WS-Security构筑安全的SOAP消息调用[M].计算机应用,2004-4.
本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。