IBM、Microsoft 和 Verisign 于2002年十二月份连系宣布了一个关于 Web 处事安详性（Web Services Security，劳务派遣管理系统，WS-Security）的类型，该类型描写如何向 SOAP 动静附加签名和加密报头；别的，它还描写如何向动静附加安详性令牌（包罗二进制安详性令牌，如 X.509 证书），提供了一套辅佐 Web 处事开拓者掩护 SOAP 动静互换的机制。

按照应用的对安详要求的级别差异，可以回收差异的方法来实现安详性，以下是今朝最常用的一些实现方法（从低到高分列）：

1. J2EE Web应用默认的会见节制（数据是明文的）；
2. 利用axis的Handler举办会见节制（数据是明文的）；
3. 利用Servlet过滤器（Filter）举办会见节制（数据是明文的）；
4. 利用SSL/HTTPS协议来传输（加密的数据传输协议）；
5. 利用WS-Security类型对信息举办加密与身份认证（数据被加密传输）。

前三种方法对付安详级别要求不高的应用是可行的，它可以或许利用Web应用会见认证机制来举办权限验证，从而掩护对资源的会见。但需要留意的是，固然它们举办了身份验证，但信息的通报照旧以明文的方法举办的，不能担保信息在传输进程中不被窃取。SSL是一个安详的传输协议，利用它传输Web处事能担保信息不被第三方窃取。但它有个缺点就是对系统资源耗损大。回收最后一种方法，信息被签名后再加密，然后把加密后的信息网络上流传，这样，纵然第三方得到加密后的传输信息，也不能解密。对付安详级别要求高的系统，应该回收WS-Security类型来作为Web处事安详性办理方案。 

二、基于https通信而且利用用户名暗码来验证的WS

在一般的应用中，我们可以通过https来掩护我们传输的明文数据。

要害在于我们需要来验证这个客户端过来的请求，即需要具有根基的用户名，暗码才气会见我的Web Service，我们称之为Basic Auth。

2.1 错误做法

在许多项目中，有些开拓步队为了图省事，客户对情况的掌控也欠好，为了验证一个webservice，我们往往会回收以下这样的验证手法：

第一种：

http://xxxx.xxx.xxx/abc.wsdl?username=验证个头&password=验证个头

处事端拿到这个url把username，password用request.getParameter出来后，和数据库一匹配，验证。

第二种：

<Request xmlns="http://10.225.106.35">

    <username>验证个头啊</username>

    <password>不要总是你个头你个头</password>

    <BusinessData>2007-01-01</BusinessData>

</ Response >

处事端拿到后把这个soap request body中的<username>和<password>拿出来后和数据库一匹配，又验证了！

这两种做法，劳务派遣管理系统，无疑是掩耳盗铃！！！（不要和我说业务实现是最主要的，等你的数据哪天没了，厂长司理的人为被改动了，假如你愿意被客户做成东方不败，那你尽量去这样做就好了。）

2.2 正确的做法

苏州软件公司 这两种做法" src="/uploads/allimg/c180218/151XaO3A420-111F.jpg" />

通过上图我们可以看到，假如你的用户名和暗码和处事端预设的用户名暗码假如不匹配，你的“挪用”，基础达到不了详细的Web Service，直接在Web Server端已经被打返来了，即你连wsdl都达到不了。

三、实际例子

3.1 Service端

我们编写一个Service端

苏州软件公司 这两种做法" src="/uploads/allimg/c180218/151XaO3963P-2c12.jpg" />