soap协议精选(九篇)

第1篇：soap协议范文

关键词：Web服务；简单对象访问协议；数字签名；可扩展标记语言

中图分类号：TP393文献标识码：A文章编号：1009-3044(2008)06-1pppp-0c

Study on SOAP Security Expansion-Based of Web Services

FAN You-lei1,ZHANG Ya-zhen2

(1.A0513 Class,Faculty of Information Science&Technology,Jiujiang University,Jiujiang 332005,China;(2.Faculty of Information Science&Technology,Jiujiang University,Jiujiang 332005,China)

Abstract: SOAP is a XML-based communication protocol.In this article,we discuss Web Services architecture of SOAP-based and SOAP message construct,a way to solve safety of Web Service is provided through SOAP based Digital Signature that ensures the integrity and security of Web Services.

Key words: Web Services;SOAP;Digital Signature;XML

1 引言

Web服务是一种通过统一资源指示符(URI)标识的软件应用，其接口及绑定形式可以通过XML标准定义、描述和检索，Web服务能够通过XML消息及Internet协议完成与其它软件应用的直接交互。Web服务可以不用改变现有的各种应用，也不用关心它们技术的不同，利用Web服务的消息驱动机制，就可以让它们协同工作和交互。Web服务体系结构中最基础的支柱是XML消息传递。目前XML消息传递的行业标准协议是SOAP，通常服务的调用者通过在传输层协议之上绑定SOAP消息来请求服务。 随着Web服务技术的飞速发展，其在电子商务、企业应用集成(EAI),B2B应用及电子政务等多个领域正发挥着越来越重要的作用。同时在这些领域也面临着各种各样的安全威胁，如信息窃取、恶意欺骗、伪装、非法修改以及各种扰乱破坏等。为保证Web服务能够在Internet上得到广泛应用，必须保证Web服务的安全，而Web服务通信是利用SOAP消息进行的，因此Web服务安全的核心就是SOAP消息的安全。

2 Web服务的技术框架

Web服务不是一个孤立的概念或者技术，它是由一系列相关的协议来组成的，这些协议之间相互依赖、相互影响。它是计算机应用中的一个重要而崭新的体系，并在此基础上形成了一个协议互操作栈。它从开放性着眼，克服了以前电子商务的封闭性，试图解决Web服务界面层的一致性和和集成平台的开放性。

协议互操作栈[1]是新一代的协议互操作技术，它是由一系列的协议所组成，从而形成了整个Web服务的体系。这些协议包括SOAP、WSDL、UDDI等多种协议。Web服务的体系结构是一个层次结构，由网络层、接口层、描述层、平台服务层以及Web服务工作流等组成，而每层都有相应的标准协议，从而形成了一个Web服务的标准协议互操作栈。图1给出了Web服务的技术框架：

图1 Web服务的协议栈

位于协议栈最底层的为各种现有的网络协议，如 HTTP 协议，FTP 协议等，它们是与 Web 服务通信的基础。SOAP 为在不同系统之间实施平台无关的交互定义了一套基本的元规则，SOAP 是 Web 服务体系架构中服务交互的基础。WSDL 则是描述 Web 服务界面的基本工具。依靠 WSDL，Web 服务的交互界面就能被系统自动处理。UDDI 则是在动态服务集成解决方案中的首次尝试。这组技术使得底层平台对应用交互透明，应用的互操作能力得到了前所未有的提升。位于最高层的 WSFL 是Web 服务工作流协议，它是 Web 服务组合运行、互操作方面的规范。安全机制对于松散耦合的对象环境非常重要,因此需要我们对诸如授权认证、数据完整性(如签名机制)、消息源认证以及事务的不可否认性等进行详细研究。

3 Web服务中SOAP消息安全规范

3.1 SOAP协议研究

SOAP即简单对象访问协议(Simple Object Access Protocol),在最新的SOAP1.2规范[2]中，其正式的定义如下:SOAP是一种轻量级协议，用于在分散型、分布式环境中交换结构化信息。SOAP利用XML技术定义一种可扩展的消息处理框架，它提供了一种可通过多种底层协议进行交换的消息结构。这种框架的设计思想是独立于任何一种特定的编程模型和其他特定实现的语义。

3.1.1 SOAP消息交换模式

SOAP消息从发送方到接收方是单向传送，并经常以请求应答的方式实现。SOAP实现可以通过开发特定网络系统的特性优化，例如HTTP绑定使SOAP应答消息以HTTP应答的方式传输，并使用同一个连接返回请求。而忽略SOAP被绑定到的协议，SOAP消息采用所谓的“消息路径”发送，使得在终节点之外的中间节点可以处理消息。一个接收SOAP消息的应用程序必须识别应用程序需要的SOAP消息的所有部分，检验应用程序是否支持前面识别的其他消息中的必需部分并处理。如果该SOAP应用程序不是消息的最终目的地，则在转发消息之前删除前面识别的所有部分。为正确处理一条消息或者消息的一部分，SOAP处理器需要理解使用的交换方式(单向、请求位答和多路发送等)、接收方的任务、使用的RPC(如果有的话)、数据的表现方法或编码.以及其它必需的语义。

3.1.2 SOAP消息的构成

SOAP消息包含一个SOAP信封Envelope，该信封是一个XML文档。Envelope XML文档的顶级元素，它包含了两个子元素―SOAP消息头部Header和SOAP消息体Body。 SOAP:Header元素是这个对象模型中的一个可选项，这个信息是用户自定义的，用来承载与应用关系不大而需底层环境平台处理的信息，例如:公共密钥加密信息、事务处理顺序标识符、参与处理的各方所需的信息、以及远程SOAP处理程序在管理远程请求时将会需要的其它元数据。SOAP:Body元素是信封的第二个子元素。对于SOAP请求来讲，请求体中包括被调用方法定义的标签，这些标签中包含方法完成其工作所需要的信息，是SOAP消息的必不可少的部分。对于SOAP响应文档来讲，SOAP:Body元素包含作为消息结果的数据。信封中的消息体部分总是用于最终接收的消息，而头部项目可以确定执行中间处理的目标节点。附件、二进制数字及其他项目可以附加到消息体上。 如图2所示：

图2 SOAP消息的结构

3.2 WS-Security规范

为了更好地将XML安全技术适应于Web 服务环境，提出了WS（Web Services）-Security规范。WS-Security规范草案最初由Microsoft公司提出，之后由IBM公司和Microsoft公司共同更新。2002年6月，WS-Security被提交给结构化信息标准促进组织(OASIS,Organization for the Advancement of Structured Information Standards)，以促进WS-Security的标准化工作。微软和 IBM 在了第一个 Web 服务安全规范 WS-Security 后，又了一系列后续规范计划。这组规范以 WS-Security 为基础，建立一个初始规范，包括：Web 服务端点策略(WS-Policy)、一个信任模型(WS-Trust)和一个隐私权模型(WS-Privacy)。

在这个基础上又建立了后续，包括:安全会话(WS-SecureConversation) 、联合信任 (WS-Federation)、授权(WS-Authoriza-

tion)。描述如何向SOAP 消息附加签名和加密报头。另外，它还描述如何向消息附加安全性令牌（包括二进制安全性令牌，如 X.509 证书和 Kerberos 票据）。如图3所示：

图3 Web-Security层次模型

(1)WS-Policy

描述中介体和端点上的安全性(和其它业务)策略的能力和限制(例如，所需的安全性令牌、所支持的加密算法和隐私权规则)。WS-Policy用于Web服务的组织为其Web服务指定安全需要。

(2)WS-Trust

用于建立自接和信任关系(包括第三方和中介体)的模型。模型描述如何通过创建安全性令牌，保证服务把现有的自接信任关系用作信任的基础。

(3)WS-Privacy

创建、管理和使用Web服务的组织将经常需要声明它们的隐私权策略，并要求进来的请求声明发送者是否遵守这些策略。

(4)WS一SecureConversation

描述Web服务如何认证请求者消息、请求者如何认证服务以及如何互相建立认证的安全性上下文，以及描述如何建立会话密钥、派生密钥和消息令牌密钥。

(5)WS-Federation

这个规范定义如何使用WS-Security，WS-Policy,WS-Trust,WS-SecureConversation规范构建联合信任案例。例如，它将描述如何把Kerberos和PKI基础架构联合起来。同时还引入一个信任策略来指出并限制和确定被的信任类型。

(6)WS-Authorization

这个规范将描述如何指定和管理Web服务的访问策略。它将特别描述如何在安全性令牌内指定声明，以及这些声明在端点处将如何被解释。

WS-Security规范本身并没有定义新的安全协议，而是在己存在的安全标准和规范中强调安全性。它提供了一个可扩展的框架，用来在SOAP消息中嵌入安全性机制包含数字签名、消息摘要和数据加密等。这些安全性信息都是作为附加的控制信息以消息的形式传递的，不依赖于任何传输协议。因而WS-Security规范具有传输中立性，能保证端到端的安全性。消息级安全模型相对于传统平台/传输级(点到点)的安全模型而言，更适合用于异构环境中，还能有效地防止消息在经过中间节点时遭到第三方的破坏。

4 SOAP消息安全性扩展

Web服务的安全性问题涉及的议题虽然相当广泛，但是首先要解决的基本问题是Web服务通信安全问题，即基于XML的SOAP消息的安全性问题。Web服务的通信安全首先要保证通信中传输的数据的安全，抵抗窃听、篡改、假冒、重放、业务否认等安全攻击，确保数据的机密性、完整性、可用性、消息源认证性和不可否认性。其中，机密性是指消息接收者能够识别消息内容，而入侵者无法识别消息内容；完整性是指消息接收者能够验证传输过程中消息没有被篡改；可用性是指消息接收者能够正确获取所需的消息内容；消息源认证性是指消息接收者能够确认消息的确来源于消息发送者，且入侵者不可能伪装成消息发送者发送同样的消息:不可否认性是指消息发送者无法否认他己经发送过的消息，消息接收者也无法否认他己经接收到的消息。这些安全需求仅依靠SSL的安全机制不能解决所有的问题。SOAP信息封套(Envelope)包括两个部分：SOAP信息头(Header)和SOAP信息体(Body) 。SOAP信息头主要包含与请求相关的元数据，而SOPA信息体封装了服务调用及其相关的参数。通常，认证信息是作为元数据和SOAP消息一起发送的，而且数字签名也可以被容纳在SOAP信息头中.因此，SOAP信息头在SOAP安全中起着重要的作用。因此必须是通过对soap消息头进行安全的扩展，而对于SOAP进行安全性扩展，数字签名(Digital Signature)又是一个很好的解决方案。

4.1 SOAP消息头数字签名的实现

数字签名技术是使用加密算法制成的数字标签，此标签通过密钥制成，而且不访问密钥，就不可能仿制标签。通常使用私钥签名文件,并使用同一私钥打开别人发送来的加密文件。具体将要满足如下三个要求：

(1)接收者能够核实发送者对消息的签名；

(2)发送者事后不能抵赖对消息的签名；

(3)接收者不能伪造对消息的签名。

现在对SOAP进行扩展,在SOAP的头元素的扩展命名空间中加入数字签名。下面是一个包含数字签名的SOAP信息[3]:

＜ SOAP-ENV: Envelope

xmlns: SOAP-ENV = " schemas. xmlsoap. org/soap/envelope/ "＞

＜ SOAP-ENV: Header ＞

＜ SOAP-SEC: Signature

xmlns: SOAP-SEC = " schemas. xmlsoap. org/ soap / security/2000-12"＞

＜ ds: Signature xmlns: ds = " http: // w3. org/2000 /09 /xmldsig#"＞

＜ ds :SignedInfo ＞

＜ ds :CanonicalizationMethod

Algorithm =“http :// / TR/ 2000/CR-xml-c14n-20001026＞ ”

＜/ds :CanonicalizationMethod ＞

＜ ds :SignatureMethod

Algorithm =“http :// /2000/9/ xmldsig # dsa =“sha1“/ ＞

＜ ds: Reference UR I= "#Body"/＞

＜ ds : SignatureValue ＞ iPUoju1hu4o7UTYJKL

＜ /ds : SignatureValue＞

＜/ds :SignedInfo ＞

……

＜ ds : SignatureValue ＞ ioikUERii47yukjkdk

＜ /ds : SignatureValue＞

＜/ds: Signature＞

＜/SOAP-SEC: Signature ＞

＜/SOAP-ENV: Header＞

＜ SOAP-ENV: Body

xmlns: SOAP-SEC = schemas. xmlsoap. org/ soap / security/2000-12

SOAP-SEC: id = "Body"＞

＜m: GetFirstStudent xmlns:m = “some-URI“＞

＜m:symbol ＞ BeiJing University＜/m:symbol＞

＜/m: GetFirstStudent ＞

＜/SOAP-ENV: Body ＞

＜/SOAP-ENV: Envelope ＞

SOAP头元素的扩展命名空间中加入安全特征，通过扩展，在方案中加入一个新的元素,这个元素在Schema中可以不用改变。如果要在SOAP1.1协议中进行加密性扩展,可以在命名空间中引入适当的标准实现，如XML加密算法(XML Encryption)等。SOAP头元素SOAP-SEC使用的XML命名空间[4]如下：http: ///soap/security/2000-12,命名空间的前缀“SOAP-SEC”就指向这里。

5 结束语

随着B2B、B2C电子商务的发展，企业要求能够与它的业务伙伴、顾客和供应商实现跨边界的、快速的、无缝的整合，而Web服务的通信是利用SOAP消息进行的，SOAP 消息常常跨越 Internet进行传递，因此消息的完整性显得尤为重要。作者在基于WS-Security规范的基础上，采用数字签名方式对SOAP消息头进行安全扩展,确保消息的完整性，但是web服务安全方面，仍有许多值得探索和研究的地方，相信随着W3C标准化进程的发展，SOAP的技术标准也会不断得到补充和完善，SOAP应用必定会更加广阔。

参考文献：

[1]李安渝,等.Web Services技术与实现.北京:国防工业出版社,2003:8-11.

[2]W3C Recommendation Version 1.2 Part0:Primer.[EB/OL]./TR/2003/REC-soap12-part0-20030624/.

[3]W3C SOAP Security Extensions: Digital Signature[EB/OL]./TR/2001/NOTE-SOAP-dsig-20010206.

[4]XML-Signature Syntax and Processing[EB/OL]./TR/2000/CR-xml-dsig-core-20001031,2000-10.

第2篇：soap协议范文

关键词:Web Service;XML;SOAP;UDDI;面向组件

中图分类号:TP393文献标识码:A文章编号:1009-3044(2009)13-3389-03

1 引言

如何提高异构操作系统平台、不同应用系统之间的互操作性是分布式计算技术发展的需要解决的问题;随着异种计算环境的不断增加,各种系统和平台间的互操作性就更加显得重要。正是在这种技术发展的趋势下,Web Service技术应运而生,它定义了一套标准的调用过程使得客户端能够调用其服务。

2 Web Service概述

近年来,Web Services(Web服务)获得了巨大的发展。许多软件公司纷纷宣布了对Web Service的支持和应用。并有很多组织参与了Web Service标准的完善。W3C Web Service Architectrue小组为Web服务暂行的定义是:“Web服务是由URL标识的软件应用程序,器接口和绑定可以通过XML(eXtensible Markup Language)构件进行调用、描述和发现,Web服务支持通过基于因特网的协议使用XML的消息与其他软件应用程序直接交互。”

我们可以这样认为,Web服务是一种新型的Web应用程序,具有自包含、自描述以及模块化的特点,可以通过Web、查找和调用。Web Service实现的功能可以是响应客户一个简单的请求,也可以是完成一个复杂的商务流程。一旦一个Web Service配置好后,其它应用程序和其它Web服务e就可以直接发现和调用该服务。

3 Web Service特征

1) 完好的封装性:服务是一种部署在Web上的对象,自然具备对象的良好封装性,对于使用者而言,能且仅能看到该对象提供的功能列表。

2) 松散耦合:当一个Web Service的实现发生变更的时候,调用者是不会感到这一点的,对于调用者来说,只要服务的调用接口不变,服务实现任何变更对他们来说都是透明的。

3) 使用标准协议规范:作为Web Service,其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。这些标准协议具有完全免费的规范,以便由任意方进行实现。

4) 高度可集成能力:由于服务采取简单的、易理解的标准协议作为组件接口描述规范和协同描述规范,完全屏蔽了不同软件平台的差异,无论是CORBA(通用对象架构),DCOM(分布式组件对象模型)还是EJB(Enterprise JavaBeans)都可以通过这一种标准的协议进行互操作,实现了在当前环境下最高的可集成性。

4 Web Service核心技术

Web服务技术核心的标准有XML(Extensible Markup Language可扩展标记语言)、SOAP(Simple Object Access Protocol简单对象访问协议)、WSDL(Web Services Description Language Web服务描述语言)和UDDI(Universal Description Discovery and Integration统一描述、发现和集成)。XM

4.1 XML( Extensible Markup Language可扩展标记语言)

XML是W3C推荐参考通用标记语言,它是 SGML( Standard Generalized Markup Language标准通用标记语言)的子类,可以定义自己的一组标记,它具有下面几个特点。

1)XML是元语言;

2)允许通过使用自定义格式,标识、交换和处理数据库可以理解的数据;

3)基于文本的格式,允许开发人员描述结构化数据并在各种应用之间发送和交换这些数据。

4)有助于在服务器之间传输结构化数据。

XML文档的组成主要有:声明 、元素、注释、字符引用和处理指令。其中声明必须作为XML文档的第一行,前面不能有空白,注释或其他的处理指令,它的完整格式为。

元素:在XML中,元素分为非空元素和空元素两种类型,一个XML非空元素是由开始标记、结束标记以及标记之间的数据构成的,开始标记和结束标记用来描述标记之间的数据,标记之间的数据被认为是元素的值。而空元素就是不包含任何内容的元素,即开始标记和结束标记之间没有任何内容的元素。

注释:注释以“

字符引用:分为实体引用和CDATA:实体引用的作用是当在字符数据中需要使用特殊符号时,可以使用实体引用来代替这些特殊符号。CDATA以“”作为结束,段开始和段结束之间的内容称为CDATA段的内容,解析器不对CDATA段的内容做处理。

下面是一个完整的XML文档:

-------------XML声明

----------文档类型声明

]>

-----------------注释

-----------------根元素开始标记

2.00

3.00

& PRICE ;

字符引用

XML标准是Web Service技术应用的基石,XML的数据独立性将内容与其表示分开,使结构化数据可以在不同平台和应用程序之间移植。WSDL文档、SOAP消息格式等都遵循了XML标准的定义。XML的使用可以以平台无关的方式与其他用户和程序进行数据交换,所以XML的数据描述机制提供了强大的方式来共享数据。

4.2 SOAP (Simple Object Access Protocol简单对象访问协议)

W3C组织对SOAP定义是:SOAP是一种轻量级协议,用于在分散型、分布式环境中交换结构化信息。SOAP利用XML技术定义一种可扩展的消息处理框架,它提供了一种可通过多种底层协议进行交换的消息结构。这种框架的设计思想是要独立于任何一种特定的编程模型和其他特定实现的语义。

SOAP规范主要由三个部分组成

SOAP信封 (envelope ):它构造定义了一个整体的SOAP消息表示框架,可用于表示消息中的内容是什么,是谁发送的,谁应当接受并处理它,以及这些操作是可选还是必须得。

SOAP编码 (encoding rules):定义了一个数据的编码机制,通过这样一个编码机制来定义应用程序中需要使用的数据类型,并可用于交换由这些应用程序定义的数据类型所产生的实例。

SOAP RPC表示(RPC representation):定义了一个用于表示远端过程调用和响应的约定,例如如何使用HTTP或STMP协议与SOAP绑定,如何传输过程调用,在具体传输协议的哪个部分传输过程响应,如可在HTTP的响应时候传输过程响应。

SOAP消息框架:SOAP消息是一个XML文档,它由三个部分组成。

Envelope:定义各个SOAP消息会使用的命名空间和附加属性。

Header:可选的元素,如果出现必须作为Envelope元素的第一个直接子元素出现。主要携带认证、事务处理和支付的辅助信息。

Body:必选的元素,消息的主要有效载体。

下面是SOAP文档的标准样式:

Xmlns: SOAP-ENV=“/soap/envelope ”

SOAP-ENV:encodingstyle=“/soap/encoding”>

………

…………

下面是一个简单的Java程序

public class Hello

public String getName(String name)

{

return “hello”+name; }

此时SOAP请求消息为

Xmlns: SOAP-ENV=“/soap/envelope ”>

huxiang

4.3 WSDL(Web Services Description Language Web服务描述语言)

WSDL是一个提供描述服务接口定义语言标准方法的XML词汇,其主要目的在于Web Service的提供者将自己的Web Service的所有相关内容,如所提供的服务的传输方式、接口参数、服务路径等生成相应的完全的文档,给使用者。使用者可以通过这个WSDL文档,创建相应的SOAP请求消息,通过HTTP传递给Web Service提供者,Web Service在完成服务请求后,将SOAP返回消息传回请求者,服务请求者再根据WSDL文档将SOAP返回消息解析成自己能够理解的内容。W3C组织在2000年9月了WSDL标准,Web Service描述工作组(Web Services Description Working Group)在2004年8月推出了WSDL2.0 规范。

下面是一个WSDL文件,描述了通过订单号获取订单详细信息的Web服务。

targetNamespace="um:OrderManage"

xmlns="/wsdl/"

xmlns:wsdlsoap="/wsdi/soap/"

xmlns:xsd="/200I/XMLSehema">

Type="intf.:OrderDetailService">

transport="/soap/hnp"/>

encodingStyle="/soap/encoding/"

namespace =" um :OrderManage" use="encoded"/>

encodingStyle="/soap/encoding/"

namespace= "urn :OrderManage" use=" encoded"/>

name ="OrderDetailService">

从上面的WSDL文档可以看出,一个完整的WSDL文档由三个部分组成:

1)服务内容:包括接口名称(portType),接口操作(operation),输入和输出消息(input message、output message),输入和输出变量(types)。

2)绑定类型、传输协议:包括绑定名称(wsdl:binding)指向响应的接口名称、绑定方式(soap:binding,通过Transport定义传输协议,通过Style定义绑定类型)、每个接口操作的每个输入和输出消息的绑定类型(nput message、output message)。

3)服务地址:包括wsdl:port指向绑定,address指向服务位置。

4.4 UDDI (Universal Description Discovery and Integration统一描述、发现和集成)

UDDI由Ariba、IBM和Microsoft三家公司创立,并且被W3C采纳的,是Web Service描述与发现的标准协议和Web Service集成的系统框架,它创建了一个标准的具有操作性的平台,相关的组织或个人可以将提供的Web Service在UDDI平台上,同时可以使得公司和应用程序可以快速、容易和动态地在网络上发现和使用。

由于WSDL文件已经给定了Web Service的地址URI,外部可以直接通过WSDL提供的URI进行相应的Web Service调用,所以UDDI并不是一个必需的Web Service组件,服务方完全可以不进行UDDI注册也是可以的。

5 结束语

Web Service本质上一个服务组件,它的特点是将面向对象的程序进一步封装,它的里面包含了一些粗粒度的接口,我们可以通过服务描述语言WSDL来描述服务,通过SOAP协议来实现不同厂商之间的Web Service调用,通过UDDI来和发现Web Service。通过对它的研究,对于面向组件的编程具有重要意义,它的兴起,标志着以组件为导向的IT时代的来临。

参考文献:

[1] 柴晓路,梁宇奇.Web Services技术、架构和应用[M].北京:电子工业出版社,2003.

[2] Sturm J.开发XML解决方案[M].北京:北京大学出版社,2002.

[3] 邓正宏,薛静,邓玉山.面向对象技术[M].北京:国防工业出版社,2004.

第3篇：soap协议范文

关键词：Web Service；Ajax；SOAP协议

中图分类号：TP393文献标识码：A文章编号：1009-3044(2008)11-20341-02

1 前言

Web Service主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。Web Service所使用的是Internet上统一、开放的标准，如HTTP、XML、SOAP、WSDL等，所以Web Service可以在任何支持这些标准的环境（Windows、Linux）中使用。Web Service技术的不断成熟，使得面向服务的架构（SOA）思想得到了很好的应用。

Ajax引擎实现无需页面无刷新等待的情况下，进行与服务器之间的数据通信，使用它可以构建更为动态和响应更灵敏的Web应用程序。基于SOAP协议，通过Ajax调用Web服务，实现异构程序和平台无关的数据通信。

2 关键技术

2.1 Ajax

在Ajax之前，WEB站点强制用户进行提交、等待、重新加载的模式，用户的动作和服务器的反应同步，Ajax提供与服务器异步通信的能力。通过Ajax用户通过JavaScript和DHTML向服务器发出异步请求，执行更新或查询数据，当请求返回时来更新UI，而不是刷新整个页面，降低了与服务器之间通信的数据量，加快了用户请求的反应时间。

在WEB浏览器使用SOAP服务比较困难，大多数流行的WEB浏览器在生成和处理XML方面会有不同，支持XML处理的API比较少。比较常见的方法是通过XMLHttpRequest API，XMLHttpRequest是一个用于执行异步HTTP请求的JavaScript对象。AJAX框架的关键是名为XMLHttpRequest的JavaScript对象，通过它客户端开发人员可以在不打断用户操作或者在充分使用隐藏表单的情况下通过HTTP直接发送和接收XML文档。现在常用的浏览器（IE, Mozilla, Safari, Opera）都特别提供了对XMLHttpRequest对象的支持，同时也广泛支持XML DOM。

2.2 SOAP

目前有很多应用程序通过使用远程过程调用（RPC）在诸如 DCOM 与 CORBA 等对象之间进行通信，但是，RPC会产生兼容性以及安全问题；防火墙和服务器通常会阻止此类流量。通过HTTP在应用程序间通信的就是更好的方法，因为HTTP被所有的因特网浏览器及服务器支持。SOAP（Simple Object Access Protocal，简单对象访问协议）可以完成这个任务的。SOAP提供了一种标准的方法，使得运行在不同的操作系统并使用不同的技术和编程语言的应用程序可以互相进行通信。SOAP技术用于实现异构程序和平台间的数据交换，从而能够使应用能被广泛地访问。SOAP是将基于HTTP的WEB技术与XML的灵活性和可扩展性组合在一起。

SOAP消息处理框架定义了一套XML元素，封装XML消息以便在系统中间进行传输。该框架包含的核心XML元素有Envelope，Header，Body和Fault，目前常见SOAP消息有1.1和1.2两个版本。Envelope是SOAP消息的根元素。Envelope元素包含一个可选的Header元素，一个必须的Body元素，Body元素包含所以的调用和响应信息。Fault元素提供处理此消息发生的错误。HTTP协议绑定定义了在HTTP上使用SOAP的规则。SOAP请求、响应映射到HTTP协议请求、响应模型。对于SOAP消息使用POST方式进行请求，SOAPAction表示该消息的意图。

3 WEB Service架构

实现通过页面异步调用目标服务器的一个Web服务，所用开发环境是Visual studio2005。首先创建 Web服务，提供实现两个整数相加的服务。继承WebService实现MyService类，在WebService继承类中可以提供Web方法和非Web方法，在方法前标注[WebMethod]，表示该方法是一个Web方法，Add方法就是一个Web方法。示例代码：

[WebService(Namespace = "/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class MyService : System.Web.Services.WebService{

[WebMethod]

public int Add(int i ,int j) {

return i + j;

}

}

然后在Web页面中添加SOAP消息的请求，这里通过Ajax进行发送请求SOAP消息，由于XMLHttpRequest不是一个W3C标准，所以可以采用多种方法使用JavaScript来创建XMLHttpRequest的实例。Internet Explorer把XMLHttpRequest实现为一个ActiveX对象，其他浏览器（如Firefox、Safari和Opera）把它实现为一个本地JavaScript对象。示例代码：

function getXmlHttpRequestObject() {

if (window.XMLHttpRequest) {

return new XMLHttpRequest(); //Not IE

} else if(window.ActiveXObject) {

return new ActiveXObject("Microsoft.XMLHTTP"); //IE

} else {

alert("not supported");

}

}

接着将SOAP消息发送，XMLHttpRequest的readyState属性返回当前请求的状态，0表示未初始化，4表示上次数据接受完毕，这两个状态下都可以开始一个新的请求。然后通过open方法创建一个新的Http请求，并指定此请求的方法。通过onreadystatechange设置readyState属性改变时的事件处理句柄。示例代码：

function sendRequest(){

if (receiveReq.readyState == 4 || receiveReq.readyState == 0) {

receiveReq.open("POST", "MyService.asmx", true);

//SOAP1.1

receiveReq.setRequestHeader ("Content-Type","text/xml; charset=utf-8")

receiveReq.setRequestHeader ("SOAPAction", "/Add") ;

var msg="＜?xml version=\"1.0\" encoding=\"utf-8\"?＞"

+"＜soap:Envelope xmlns:xsi=\"/2001/XMLSchema-instance\"

+" xmlns:xsd=\"/2001/XMLSchema\"

+" xmlns:soap=\"/soap/envelope/\"＞"

+" ＜soap:Body＞"

+"＜Add xmlns=\"/\"＞"

+"＜i＞1＜/i＞"

+"＜j＞2＜/j＞"

+"＜/Add＞"

+" ＜/soap:Body＞"

+"＜/soap:Envelope＞"

receiveReq.onreadystatechange = handleAdd;

receiveReq.send(msg);}

}

示例代码中，setRequestHeader设置http封装格式，变量msg的内容就是SOAP1.1格式的消息请求，进行两个整数i和j的相加请求。将onreadystatechange设置为函数handleAdd，进行SOAP消息响应的处理。

最后是对SOAP消息响应的处理，readyState属性为4表示接受完毕，根据http请求状态status为200表示http响应成功，返回如果是字符串可以通过responseText属性获取，如果是xml文件可以通过responseXML属性获取。示例代码：

function handleAdd() {

if (receiveReq.readyState == 4) {

if (receiveReq.status==200){

// 对receiveReq的响应responseXML或responseText进行处理

} else {

alert("status:" + receiveReq.statusText);

}

}

}

4 结束语

本文中，介绍了基于SOAP协议架构WEB Service的步骤，但是这个过程没有提供安全性解决方案。对于一个真正安全的WEB Service来说，证书、密钥和加密同样是必不可少的。最健壮的WEB Service安全性源于实现了使用来自认证机构的私钥、公钥进行身份验证的加密消息传递。XML加密允许web服务用户发送保留XML格式的加密SOAP消息。

参考文献：

[1] W3C. SOAP:Simple Object Access Protocol Specification1.1 .2000.

[2] Nicholas C Zakas, Jeremy McPeak, Joe Fawcett. Professional Ajax .Wiley Publications, 2006.

[3] Christian Gross. Ajax Patterns and Best Practices[M]. Apress L P, 2006.

[4] 王东,孙彬. 基于Ajax的MVC框架的改造分析[J]. 计算机应用, 2007,(S1):293-295.

[5] 程亚娟, 赵政. XML数据存取技术[J]. 微型机与应用, 2002,(01):59-60.

第4篇：soap协议范文

【关键词】SOAP；XML签名；XML加密

SOAP以XML形式存在并被封装在HTTP等TCP/IP应用层协议中，是Web Service组件间的标准通信协议。WSS4J是一个签名和验证SOAP消息的Java库，符合W3C有关XML签名和XML加密的规范。WSS4J利用Apache Axis作为SOAP Engine，以Apache XML-Security为XML安全引擎。本文利用Apache Axis和WSS4J提供的Web安全服务框架，对Web服务中SOAP消息的安全传递作了研究。

1.在Axis Web服务中使用WSS4J

Axis采用管道过滤器模式处理请求流和响应流，Axis中的过滤器就是handler，根据具体的处理任务按调用的顺序它们被组织在请求/响应流中。通过handler可在处理链（handler chain）中卸载与嵌入第三方功能模块来实现系统功能的扩展和模块化。WSDoAllSender和WSDoAllReceiver是用于WSS4J的Axis handler，它们都是org.apache.axis.handlers.BasicHandler的扩展类，前者用于XML消息的加密、签名，后者用于XML消息的解密、验证，可以使用这些安全handler截获进出客户/服务器的SOAP消息并进行安全处理，如图1所示。

我们可采用Axis handler的标准配置方式，通过Axis的Web服务部署描述符文件（WSDD）中包含必要的信息来控制安全过程，完成安全SOAP消息的创建和使用。Axis Web服务在客户端为用户构造Web services请求，接收应答并返回给用户；在服务器端接收请求，用收到的SOAP消息中的数据调用相应的服务并返回应答。客户端应用程序通过调用Axis提供的API来调用目标服务。Axis在收到请求后将调用WSDoAllSender handler进行安全处理，最后经特定于传输的handler将消息发送出去。其中，Axis解析部署描述符文件并将相关参数和相应的值提供给WSS4J handler，安全handler解释参数值并调用WSS4J模块来处理SOAP消息，而WSS4J则使用Apache XML-Security项目提供的XML签名和XML加密机制来完成XML消息签名加密。

2.基于UsernameToken令牌的用户认证

为了实现用户身份认证，需将令牌Username Token插入到SOAP请求中，它包含一个明文形式的用户名和相应的口令。作为敏感信息的口令一般不以明文形式存储。为了得到相应的口令，WSS4J handler使用了类似JAAS机制（Java验证和授权服务）的password callback技术，如图2所示。

部署描述符文件中的passwordCallback Class参数包含callback类的类名，这个类必须实现CallbackHandler接口。WSS4J handler得到这个类，实例化，当需要口令时则调用该类的handle方法来获得。

客户端的部署描述符文件client-side.wsdd：

服务器端的部署描述符文件server-side.wsdd：

客户和服务器都需要一个Callback类的Callback Handler用以确认用户验证的有效性，当用户名/口令无效时则抛出异常。

3.签名加密XML消息

可通过配置客户和服务器端的WSDD文件（如下所示）实现XML消息签名加密，参数encryptionParts取值为Element时是对元素加密，为Content时是对元素内容加密，该参数缺省时表明对整个XML消息体加密。同时还需要创建keystore文件，签名和加密时可使用同一个keystore属性文件。参数signaturePropFile和decryptionPropFile指明所用的keystore文件名，分别用于客户/服务器进行签名、加密和解密。我们通过签名和加密第2节的用于身份认证的XML元素UsernameToken，完成SOAP消息签名加密的功能，并可利用SOAPMonitor工具捕获签名加密后的SOAP消息。

客户端的部署描述符文件client-side.wsdd：

服务器端的部署描述符文件server-side.wsdd：

4.结论

Axis Web服务屏蔽了底层技术细节，利用它提供的handler便于将用户加密认证模块插入到请求/响应处理链中，通过对填充装于SOAP消息中的XML文档进行加密认证，实现了SOAP的机密性和完整性。如果进一步提高SOAP消息中XML签名加密的粒度，则可更好地确保Web服务通信安全。

作者简介：

第5篇：soap协议范文

关键词： XML；SOAP；Web服务；加密

中图分类号：TP393 文献标识码：A文章编号：1006-4311（2012）07-0128-01

1Web Service中SOAP安全探讨

针对Web服务的安全需求，国内外的一些标准化组织、公司和社会团体进行了大量相关研究，并提出了很多安全规范。这些标准和技术虽然从很大程度上解决了SOAP的安全问题，但也往往存在一些不足。在SOAP消息传输中，SSL等传输层安全协议能够保证传输级消息的安全，但它有两个显著的缺点，第一是途经中间节点的解密问题，第二是SSL加密对整个消息进行加密，破坏了XML格式。在具体的应用环境下，通常仅仅需要对SOAP消息的一部分加密，这样不仅能提高加密/解密的效率，而且能使消息的格式得以保持。XML Encryption定义了对通用XML进行加密的方法，它是W3C的规范草稿，尚未成为正式标准。XML Encryption采用对称密码体制和散列函数，能够在事先协商好对称密钥的情况下，通过将消息主体替换为密文，对XML消息的单一或多个部分进行加密。SOAP是基于XML的，因此可以将XML Encryption的方法应用到SOAP的安全应用中。从而实现SOAP的安全传输。

2SOAP的加密的实现方法

SOAP的加密过程中首先对要加密的SOAP文档按照XML DOM进行解析，找出要加密的节点对象，采用具体的加密算法对该对象进行加密，同时做加密算法的声明。SOAP的解密过程先对接收到的SOAP文档进行解析，找出加密节点对象，根据加密算法的声明选择相应的解密算法。

在下面的实现中，可以通过对XmlDocument对象进行解析，找出需要保护的数据，然后实例化加密算法，根据需要可以选择不同的加密算法，最后对重要数据进行加密，从而实现SOAP的保密传输。

通信平台中截获SOAP请求Body中要加密的元素< customer>如下：

< name> lisi< phone> 765756765

< CreditCard Limit= "5000"Type= "Visa"> 78778< /CreditCard>

< /customer >

下面是SOAP消息的加密后的XML文档。Body条目中< CreditCard>被对称加密方法加密了，对称密钥作为其中的一个条目，同时该条目采用非对称加密后，以元素的形式出现。也就是说，这个密钥是使用公钥加密的（这是一个常用的加密模型，文档数据使用诸如DES等对称加密算法加密，而加密的对称密钥则使用非对称的RSA加密算法加密）。

对Customer的XML文档中的信息进行加密会得到如下密文：

< KeyName>zhangsan

< CipherValue> Oll……Ay4=< /CipherValue> < / CipherData>

1Qab……Uw2og= =

观察加密后的密文，可以看到上面描述的各个元素，首先,元素显示了AES-256的URI,这意味着该文档的加密算法是用带有256位密钥的AES算法。密钥在元素中加密,通过观察元素可以看到它是用RSA算法并借助一个名为zhangsan的密钥加密的（接收方公钥），元素存放了该密钥的加密值。在元素后面的是包含加密内容的元素。

3总结

基于XML Document的SOAP安全模型主要有以下几个特征: 一是它可以进行对元素属性的加密，并进行XML文档模式的转化; 二是它将SOAP进行解析，实现部分重要数据的加密；三是可扩展到XKMS从而提供了一个安全的密钥获取机制。此方法也存在一些不足：一是其安全性依赖于加密算法的选择和密钥的长度；二是在进行XMLDocument文档解析的过程中时间和空间复杂度的不确定性。

参考文献：

[1]陈天煌，李帆.利用SOAP扩展实现Web服务中SOAP消息的安全[J].武汉理工大学学报，2007.

[2]顾韵华，傅德胜，王兴.XML安全技术分析与应用[J].计算机科学，2009，36（5）：118~141.

第6篇：soap协议范文

面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（extensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了[2]。

目前Web 服务已经是实现 SOA 的一种重要的方式，以至于很多人将两者的概念混淆。现在SOA要求服务间广泛的互操作性，SOA虽然能解决异构平台下Web服务的互相调用，在开发Web服务的逻辑功能时，如果把安全特性也设计进来，使其能实现SOA安全之目标，无论对理论与技术实践，都提出了挑战。

1 异构平台安全特性

SOA要求服务间广泛的互操作性。在开发Web服务的逻辑功能时，如果把安全特性也设计进来，Web服务将变得异常复杂，服务的性能与可伸缩性会大大降低。就安全需求本身分析，仅仅把各种安全措施集合在一起，不能肯定安全组件的组织是否恰当，也不能肯定能使一个系统更加安全。因而SOA中Web服务的安全问题应与服务的功能脱离，通过适当的安全配置与安全机制实现Web服务的安全需求。这样，既能保证Web服务设计与调用的简洁性，又能实现SOAP信息传递与服务调用的安全性。

一个应用系统通常是基于某个平台实现的，如基于Microsoft .NET或Apache Axis。这些服务平台都有独立的安全解决方案，如Microsoft 的WSE（Web Service Enhancement） 、Axis 的Rampart等。对于同一个安全策略，如采用证书对消息签名，服务请求方对消息签名，服务的提供方对签名验证，在相同平台中是可以实现的。但如果请求方与服务提供方处于不同的平台中，安全的互操作性通常无法保证。

每个应用平台都有自己的安全机制与安全API，这类商业软件使用自己的策略配置为安全建模。但是，在使用SOA进行企业应用集成时，不同应用系统的服务可能在不同的应用平台上，采用不同的安全策略与平台技术实现安全需求。这时需要一个处理服务安全的机制从逻辑上包装平台安全的特定实现，使异构平台下的SOAP安全信息能够被异构平台一致地理解与处理[3] [4]。

异构平台下Web服务安全处理机制提供了相关安全策略配置与SOAP消息安全的实现方法。安全服务使用WS-Security等规范实现SOAP消息安全，分为以下三个方面：

1） 消息完整性：使用XML签名对SOAP消息进行数字签名，保证SOAP消息经过中间结点时不被篡改。

2） 消息保密性：使用XML加密对SOAP消息进行加密，使消息发送方可以确保SOAP消息内容仅对预定的接收方可见，保证SOAP消息即使被监听，监听者也无法提取出有效信息。

3） 消息真实性：引入安全令牌的概念，用其代表消息发送方的身份。通过与多种数字签名结合，消息接收者可以确认SOAP消息发送者的合法性。

2 异构平台的策略框架

2.1 NET平台WSE 3.0安全策略

在WSE的安全实现框架中，针对SOAP消息从客户端发送请求、服务端接收请求、服务端发送响应和客户端接收响应设计了四个过滤器，并分为两组。在SOAP请求后和SOAP响应前截取SOAP，然后对截取的SOAP消息的数据进行处理。每个过滤器负责一项特定任务，既可以是安全事务，也可以是跟踪等管理事务。该框架结构实现了安全逻辑与业务逻辑的分离，WSE安全框架结构如图1所示。

WSE 3.0提供的安全机制保证了Web 服务的安全。实现安全的方式有两种，一是通过WSE3.0策略工具根据应用系统的安全规格为服务端和客户端设置相应的安全策略；二是用代码实现具体的安全策略相同的功能。前者方便快捷，通过简单的设置即可完成Web服务的安全。后者用户可以定义更具体的代码来扩展自己的安全策略。不论采用那种方式都可以利用WSE 3.0提供的安全机制保证Web服务的安全交互。

由于策略由策略断言组成，并且每个断言都会在管道中插入过滤器对进入和离开终结点的SOAP消息执行预处理和后续处理。通过将断言放到策略中，可以在运行时控制构建和组织过滤器管道。在WSE 3.0中，管道是由安全策略框架驱动的。

2.2 Axis平台Rampart安全策略

Rampart的结构如图2所示，其中mod-rampart模块的作用是为Rampart和Axis2引擎提供接口。Rampart内部由Rampart引擎（Rampart Engine）、Rampart功能实体（Utile）和Rampart安全策略（Security Policy）组成[5]。

在Rampart中，Security Policy具有配置安全模块的作用。Rampart使用WS-Security Policy规范中定义的安全策

略断言进行配置，WS-Secu rity Policy中的每一个策略断言，都定义了一个断言构建器（Builders）和一个断言模型（Models）。

Rampart作为WS-Security的实现模块加载到Axis2引擎后，既可以对所有的有效服务进行安全处理，也可以选择对一个或者多个具体的服务或者某一服务中的特定方法进行安全处理。

3 异构平台Web服务安全模型

异构平台之间的安全框架、配置策略等都有较大的不同，因此实现异构平台间Web服务的安全交互必须增加一个第三方认证机构，根据客户端的请求完成相关验证，验证通过后才能发送调用Web服务的请求；根据本项目对于Web服务的安全需求.结合WS—Security和WS—Policy规范.构造了一个Web服务的安全模型系统。

3.1安全模型体系构架

该系统实现安全的基础主要是基于SOAP头的扩展.分别实现SOAP加密、SOAP签名、SOAP认证与授权、SOAP安全属性扩展（时间戳等）。对于访问控制。我们设计了Web服务访问控制器，该控制器的实现主要基于X—RBAC模型，动态的控制用户对Web服务的访问权限。遗留系统包括一个私有CA 中心，这方便了安全模型的实现，它主要负责密钥和证书的生成和管理。此外，安全日志也保证了模型系统具备审计的功能，安全策略管理器则是负责对安全策略文件的管理。安全策略库保存着Web服务所对应的特定安全

策略文件。安全模型体系架构如图3所示。

3.2安全模型组成及其功能

安全模型主要包括安全组件包（Security Utility）、访问控制器以及安全策略管理器三部分。安全组件包由若干个SOAP消息过滤器（Filter）组成。安全组件包主要功能如下：

1）消息加密：基于XML Encryption实现SOAP消息的加密以及解密功能.密钥管理基于XKMS技术。

2） 消息签名：基于XML Signature实现SOAP消息的签名以及签名验证功能。密钥管理也基于XKMS技术。

3） 认证信息处理：通过WS—Security所支持的Username/Password Token或X.509证书安全令牌实现对用户身份的认证。

4）附加安全属性：附加的安全属性主要是防止对Web服务的重传攻击，通过时间戳机制来实现。当然.附加的安全属性也可根据用户额外的安全需求进行扩展，实现更加安全可靠的S0AP消息。

3.3模型的通信过程

在介绍完整的通信过程之前，首先给出所涉及的符号及其描述，如表1所示。

通信过程说明：

·在安全通信过程开始前，服务请求者通过SOAP消息或者其他方式获得服务提供者所提供的Web方法对应的安全策略文件。

·服务请求者根据安全需求对请求消息中需要进行安全保护的部分进行签名/加密处理，然后使用服务请求者的私钥对整个消息进行签名，并使用服务提供者的公钥对整个消息进行加密，最后将结果连同证书发给服务提供者。

·服务提供者收到请求消息后，先提取消息中服务请求者的证书，验证其有效性.验证通过，利用证书所提供的公钥验证消息签名的有效性，同时解密整个消息。

·如果安全验证全部有效，则建立整个通信过程。实现对服务的调用，然后按照安全策略文件的要求对响应的消息进行安全处理后发送给服务请求者。

·服务请求者接收到经过安全处理的消息.如果通过有效的安全认证，则按照安全策略文件的要求对消息进行签名验证和解密，最终获得原始响应消息。上述通信过程都设有超时机制，若超时则重新执行整个通信过程。若在通信过程中发生致命错误，例如，认证未通过.解密、验证失败等，则终止通信，发出错误响应消息[6]。

4 研究的方向

4.1安全策略的改进

安全策略：是指在某个安全区域内（一个安全区域，通常是指属于某个组织的一系列处理和通信资源），用于所有与安全相关活动的一套规则。这些规则是由此安全区域中所设立的一个安全权力机构建立的，并由安全控制机构来描述、实施或实现的。

下一步的研究方向针对安全服务机制没有实现的安全策略，开发实现相应的安全服务。现在的安全策略都是对所有的消息进行加密，这样效率不高，资源浪费。下一步的研究准备针对部分机密消息加密，从而提高效率。

4.2 Kerberos票据

网络认证使用最为广泛的协议是Kerberos和X.504.K。Kerberos是基于对称密码机制的，X.509是基于非对称密码机制的，两者各有特色。Kerberos在分布式网络环境中得到了广泛的应用；X.509在PKI中发挥重要作用。下一步在学习研究Kerberos协议的基础之上，分析了麻省理工大学（MIT）和微软对Kerberos认证协议的实现，在此基础之上，针对Kerberos的某些局限提出并实现了一个切实可行的解决方案。

4.3通用安全模型

现阶段仅就两个具体的平台来探索了异构平台下Web服务安全交互的模型和应用。对于基于广泛平台的异构平台下的Web服务，还没有一种统一可靠的安全模式能保证SOAP消息在多平台间传输过程中的安全性，这种安全模式也是我们下一阶段研究的重点。

5 结束语

本文介绍了在 SOA构架下Web安全，具体介绍了在Microsoft .NET和Apache Axis平台下自带的不同安全策略，并且提出了在这两个异构平台一个安全模型下互相通信的模型。下一步将具体进一步研究异构平台的安全策略并验证。

参考文献：

.冉晓旻，译.北京：清华大学出版社，2003.

[2] http：//baike.baidu.com/view/21305.html？wtp=tt.

[3] 唐柳英，卿斯汉.混合RBAC-DTE策略的多角色管理[J].计算机学报， 2006，29（8）： 1419-1425.

第7篇：soap协议范文

【关键词】Android客户端；数据访问；Web Service

一、Android手机平台

Android手机平台是Google公司推出的基于Linux内核的嵌入式操作系统平台，不仅应用于智能手机，还广泛应用于平板电脑以及其他便携式设备［2］。Android操作系统是一个开放的操作系统，它是基于JAVA的系统，运行在Linux 2.6核上。在Android软件系列中包括了操作系统、中间件和一些关键应用。Android SDK提供多种开发所必要的工具与API，这使得开发人员可以很方便的进行应用软件的开发，大大提高了开发的效率。

二、Web Service

Web Services是一种基于SOAP协议的远程调用标准。通过Web Services可以将不同操作系统平台，不同语言、不同技术整合到一起。PC版本的Web Services客户端类库非常丰富，例如，Axis2、CXF等，但这些类库对于Android系统过于庞大。适合手机的Web Services客户端类库也有一些。比较常用的为Ksoap2。

1.SOAP简介

简单对象访问协议（SOAP）是一种轻量的、简单的、基于XML的协议，它被设计成在WEB上交换结构化的和固化的信息。SOAP可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。

2.Web Service功能

Web Services是由企业的完成其特定商务需求的在线应用服务，其他公司或应用软件能够通过Internet来访问并使用这项在线服务。用简单点的话说，就是系统对外的接口！它是一种构建应用程序的普遍模型，可以在任何支持网络通信的操作系统中实施运行；它是一种新的Web Services应用程序分支，是自包含、自描述、模块化的应用，可以、定位、通过web调用。Web Services是一个应用组件，它逻辑性的为其他应用程序提供数据与服务。各应用程序通过网络协议和规定的一些标准数据格式（Http，XML，Soap)来访问Web Services，通过Web Services内部执行得到所需结果。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Services应用程序可以发现并调用它部署的服务。

三、使用Ksoap2访问Web Service

通过以上的分析，接下来我们采用一个例子来说明如何访问Web Service。该例子中使用第三方类库（Ksoap2）来获取服务器的用户数据，然后在Android客户端中显示出来。

1.Web Service部署

本例中Web Service开发工具采用Visual Studio 2010，数据库选择SQL Server 2005，用C#来实现Web Service的接口功能。

（1）建立一个Web Service的项目MyWebService。

（2）新建一个Service1.asmx的接口文件，并且新建一个WebMethod的函数方法，主要代码如下：

2.Ksoap2访问

在Android SDK中并没有提供调用Web Service的库，因此，需要使用第三方类库（Ksoap2）来调用Web Service。Android开发采用eclipse工具，因此要先配置好eclipse的开发环境。

（1）下载Ksoap2包：打开网址/p/ksoap2-android/将下载后的jar文件复制到Eclipse工程的lib目录中（如果没有该目录，可以新建一个，当然，也可以放在其他的目录中），并在Eclipse工程中引用这个jar包。右键点击Project->Propertied->Java Build Path->Libraries->Add External JARs->选择ksoap2-android-assembly-2.4-jar-with-dependencies.jar。

第8篇：soap协议范文

关键词：SOAP Web Service SQL欺骗攻击 Web Services的广泛应用使当今互联网上应用程序之间的通信日益增加。Web Service已经成为各大公司进行电子商务革命的理想选择。

SOAP（简单对象访问协议）也已经成为W3C推荐的标准，SOAP的目的是使各种不同的组件实现远程通信时就像在本地一样。

1、 SOAP通信

SOAP是一种简单、轻便的以XML为基础的协议，在Web上进行结构化、类型化数据的交换。SOAP的Envelope结构有两种：请求和响应。

请求Envelope包括了进行远程调用所需的信息。每个调用消息包括消息头和消息体。消息头存储消息路由，安全信息等内容，消息体存储的是处理调用所需的信息。包括以下几个内容：

? 调用的服务的名称

? 服务的位置

? 传给服务的参数名和数据

响应Envelope返回结果数据。成功返回的响应包括以下几个内容：

? 调用的方法

? 返回值的类型

? 返回的数据

2、SQL欺骗攻击SOAP Web 服务的实例

SQL欺骗攻击是经常使用的攻击方式。

一般Web Service把客户端传递的参数作为String来接收，如果服务没有对字符串做严格的输入检查，也就是说对输入参数进行验证或简化不安全的字符。那么，程序很容易就受到SQL欺骗攻击。比如，攻击者在参数中加入了一个单引号字符，程序在接收参数时如果不做检查，程序根据输入的参数生成了SQL查询语句，而单引号的出现势必会引发不安全的返回值，这个服务就已经遭到了攻击。

当然，Web服务的方法一般都指定了每个参数的数据类型。那么攻击者尝试在一个需要整型参数的Web方法上进行SQL参数欺骗就不会那么容易。在参数字符串中加入单引号将会导致SOAP执行后返回一个客户端错误信息，进行欺骗的参数不会传给调用的方法。

2.1攻击步骤1——了解Web Service的弱点

SQL欺骗攻击的第一步是确定是否Web服务对输入参数是否进行验证和检查。下面是一个用C#编写的简单的基于SOAP的Web服务的例子。这个Web服务实现了一个简单的产品目录系统，包括产品信息、供应商信息和供应商所给的折扣。本例中我们使用的user ID 为551-457-4487，password 为123456。程序除了指定了每个参数的数据类型，还包含了每个参数的具体说明。这个服务包括以下四个方法：

图1 Web服务中的四个方法

服务将从数据库中查询出相关数据。

首先我们要了解有关服务器和参数的信息，实验1中我们将一些参数传给GetProductInformationByName方法，看看服务器对这些参数是如何响应的。同时我们知道Name参数的数据类型为String，这是很容易遭到参数欺骗攻击的一种数据类型。

图2 实验1（在name参数中输入“’”以及服务器的响应）

从上面服务器的响应可以看出,Web方法对ProductName参数没有进行最基本的参数检查。根据服务器返回的FaultString来看，Web服务存取的信息是存储在后台数据库中的。对FaultString做仔细分析，我们可以了解Web服务内部处理的过程以及问题出现在哪里。FaultString表示Web服务出现了异常。如图2所示，在FaultString的最后几行看到我们所调用的web方法是ProductInfo.ProductInfo.GetProductInformationByName(String name,String uid,String password)。内部调用ProductDBAcess.GetProductInformation(String productName,String uid,String password)用来与后台数据库通信。传入数据库中的SQL查询语句中有一个语法错误。System.Data.OleDb.OleDbException:语法错误（缺少操作符）in query expression ‘productname like ‘‘’ and providerid=’551-457-4487’ ，这句话告诉我们内部的SQL查询使用了SQL语句的LIKE表达式，应用程序根据我们给出的用来欺骗的单引号等参数生成最终的SQL查询语句。通过以上分析，我们知道既然Web服务使用了Like表达式，那么我们用通配符%作为参数，来观察应用程序如何响应。我们想定的结果是程序将返回至少一个产品记录。

图3 实验2（在参数中输入“%”及服务器响应） 从图3可以看出，正如我们所想定的，服务器返回了一条产品记录。但我们发现，服务器只返回了一条记录而不是全部的记录。逻辑上来说，输入通配符%，内部查询应该返回所有的产品记录。但是，我们定义的GetProductInformationByName方法，返回参数的类型是String而不是ArrayOfString。这是SOAP协议进行强制的类型和输入输出编码检查的一个方面。

通过实验1和实验2，我们可以得到结论——SQL的Like表达式可以返回一些我们本不能得到的信息。Web服务本应该确认用户身份，而且在技术上来说，不能显示与参数Providerid无关的产品信息。我们要进行Web服务的欺骗，我们就要想办法利用现有的用户认证得到更多的产品信息。分析GetProductInformationByName方法用户认证的执行过程，实验3中我们还是利用实验1中对name参数采用的方法，将单引号插入uid参数，看看是否会影响用户认证SQL表达式。

’

图4 实验3（在用户id参数中加入“’”及服务器返回的结果）

在这个实验的想定中，服务器返回的FaultSstring告诉我们程序是如何利用uid和password进行用户认证的。它将认证信息传给ProductInfo.ProductDBAccess.VerifyAuthentication(String uid,String Password)方法。我们在uid参数中加入的单引号直接造成了语法错误，可以看出程序并没有进行词法检查。通过从服务器返回的查询表达式的部分，我们能生成一个SQL欺骗过口令验证。生成的SQL应该是类似于Select something from sometable where userid=’551-457-4487’ and password=’’or 1=1 or password=’’，这样的参数就能骗过服务器的身份验证。。

2.2 攻击步骤2——进行SQL欺骗

图5 实验4（输入SQL欺骗参数及服务器返回的结果）

从服务器返回的结果，我们做的SQL欺骗获得了服务器的信任。我们没有输入认证密码就得到了产品数据。

同样的道理，我们将’or’’=’作为用户的uid, ‘or providerid=’787-457-1154 作为providerid进行SQL欺骗。787-457-1154是我们事先知道的用户id。那么生成的SQL语句是：select something from sometable where uid=’’ or’’=’’ and password=’’ or providerid=’787-457-1154’。服务将接收我们的SQL，返回我们想

窃取的用户信息。

图6 实验5（用户名及口令欺骗及服务器返回的结果）

3、 防范Web服务攻击

保护Web服务不被攻击需要开发人员、系统管理员和管理人员的协作。黑客们会不断地改变他们的攻击方法，所以我们需要一个完善的安全的Web应用。

防范Web服务攻击最有效的方法就是进行输入参数与返回结果的验证和检查。

在参数传给服务器之前，任何可能引起不安全因素的字符或字符串都要进行处理。去除引号，反斜线等等还不足够，最好的方法是指定一种拒绝错误的规则来过滤掉不安全的数据，包括语法和逻辑检查等等。

应用程序同样要对返回给用户的数据进行确认。同样包括SOAP中的类型检查，逻辑检查以及确保返回的对象中包含的数据没有不安全的东西。另外，程序还要确保格式的有效性，使用统一的错误报告而不是默认的错误报告，默认的错误报告通常会告诉用户太多的信息。

第9篇：soap协议范文

关键词： 区域医疗； 数据交互； 异构系统； 信息化建设

中图分类号： TN911?34 文献标识码： A 文章编号： 1004?373X（2014）02?0051?02

随着信息技术的飞速发展，各种管理信息系统已在医疗行业中得到广泛应用。同时，在新医改的推动下，建立数字化“医疗联合体”和“区域医疗平台”成为医疗信息化发展的必然趋势。但由于各个医疗部门的软硬件条件各异，部门、单位特点不同，势必造成多种关系数据库共存的局面。多种异构数据库的存在严重限制了数据共享和交互的范围。因此如何在保留原有成熟医院信息系统（Hospital Information System，HIS）的基础上，实现异构数据库间透明信息存取是首要解决的问题。

1 医疗信息系统现状

我国从20世纪90年代初逐步开始医疗信息化建设。目前各种医疗信息化系统已经开始部署到地方各级医疗机构，典型的系统包括：医院信息系统（Hospital Information System，HIS）、电子病历系统（Electronic Medical Records，EMR）、医学影像存档与通信系统（Picture Archiving and Communication System，PACS）、检验信息系统（Laboratory Information System，LIS）和超声信息系统（Ultrasound Information System，UIS）等。

为落实国家“十二五”深化医药卫生体制改革规划、物联网发展规划和电子政务发展规划，需要对卫生信息化建设及其应用提出新的要求。国家已从战略层面指出：根据当前医改对信息化发展形势的要求，“十二五”期间卫生信息化工作要在以区域卫生信息化建设为重点的互联互通和资源共享方面有所作为[1]。区域卫生信息化建设发展的一个必然阶段便是区域卫生信息化中的数据交互建设，这是区域卫生信息化建设中最重要的课题。数据交互的实现，能够满足政府更高效、更灵活、协同性更好的实现对医疗卫生的管理，帮助医疗卫生单位实现大量信息快速、有效、准确地获取、管理和传递，改进工作流程，提高工作效率。

由于国内医疗信息化建设水平参差不齐，且无统一的标准。不同的信息系统开发商在设计、实现过程中所采用的系统架构、技术方法、开发平台千差万别，势必出现不同医疗机构间相同业务类型的数据存储定义、语义表达方式不同。这些不同，形成了无数个孤立的信息系统，导致患者就诊时医生无法在第一时间内准确了解疾病史、药物治疗史、过敏史和前期检查结果等，降低诊疗效率和诊疗质量，增多患者重复检查的次数，提高诊疗成本，加重患者经济负担。 构建异构医疗数据交互平台是实现区域卫生信息化的核心环节。通过外挂中间件的方式，对医院已有的HIS不做改动的前提下，在系统间高效、安全的传输和处理基于相关医疗信息标准的医疗信息。

2 系统设计

为了异构医疗数据间的交互，首先必须建立稳定可靠的系统架构。如图1所示，该系统架构在保留原HIS和数据库的基础上通过外挂中间件的方式交互数据。当某医院有申请数据的需要时，通过HTTP请求以XML格式表示的有效数据。发送方通过数据访问模块从源数据库中提取数据，然后基于HL7的医疗信息标准进行数据转换，以WS?Security的安全机制实现SOAP消息的安全传递，保证医疗数据标准、安全、有效的传输给数据申请方。

3 关键技术

在整个异构医疗数据交互系统架构中，数据的转换、表现形式以及数据的传输安全是最核心的技术。

（1） 基于HL7的数据转换模型。医疗信息传输与交换技术标准（Healthy Level Seven，HL7）是医学信息系统应用和执行的标准，是基于消息实现数据传递的标准规范[2]，多个HIS之间进行数据的交互都是以HL7为标准的。在HL7标准中，若干个字段构成一个消息段，有一定顺序和逻辑关系的消息段构成一条消息，当某事件发生时将消息按照一定的网络传输协议传送到接收方，接收方在消息的接收、解析之后将其送往应用程序。相比于之前版本，HL7 v3版一个显著的特点就是支持可扩展标记语言，运用XML技术来加强和改善医疗系统之间的数据交换能力。

（2） 可扩展标记语言XML。XML（eXtensible Markup Language）是针对包含结构化信息的文档而设计的一种标记语言。在本系统的研发中通过以XML格式表示和传输以HL7标准建立的共享数据信息。考虑到HIS数据的复杂性，它需要在数据类型、主外键值、数据完整性约束等方面的定义，使用XML schema定义XML文档数据交换格式的标准[3]。

（3） 基于WebService和SOAP协议的异构数据源交互模型。SOAP 调用的数据和方法的表达方式是基于 XML 的、可以使数据的型和值在表达上分离， 有利于应用程序之间透明交换信息， 同时可以解决网络传输安全性问题[4]。本研究采用WebService和SOAP协议建立异构数据源交互模型，如图2所示。该模型采用XML作为数据描述语言，转换时首先通过数据交换中间件把各种异构的输入/输出数据按照描述逻辑转换为统一规则的XML文件，然后通过SOAP传输协议在各异构系统之间的Internet网络之间进行传输，最后再通过数据交换中间件完成数据转换。

（4） 异构系统安全策略。采用基于WS?Security的安全机制实现SOAP消息的安全传递，其中对XML元素加密算法由WS?Security规范提供，这种加密算法满足了消息级安全的需要[5]。同时，采用基于X.509证书的PKI技术实现对SOAP消息进行加密、解密和签名、认证，最终实现安全的SOAP消息调用。

4 结 语

本文结合HL7 V3版本的特点和XML技术的优势，提出在保留原HIS和数据库的基础上，采用外挂中间件的方式实现异构医疗数据交互的策略，构建了数据交互的系统架构，并阐述了关键技术解决方案，对实现区域卫生信息化建设环境下的医疗数据交互提供了一个切实可行的方案。

参考文献

[1] 佚名.攻坚医改难题勇担发展重任：2012年医疗卫生信息化发展与未来展望[J].中国信息界，2012（12）：40?45.

[2] Anon. HL7 version 2： health informatics [M]. [S.l.]： [s.n.]， 2010： 107?128.

[3] AHMED K Z，UMRYSH C E.用J2EE和UML开发企业级应用程序[M].康博，译，北京：清华大学出版社，2002.

[4] 徐汉川，胡润波，刘国忠.基于XML/SOAP数据交换中间件的设计[J].哈尔滨商业大学学报：自然科学版，2004，20（6）：665?670.

[5] 蔡小芳，张永胜.在Web服务安全中XML加密与签名的应用[J].计算机安全，2006（7）：20?23.