万维网最好的地方在于它的匿名开放性，允许浏览器客户端访问世界范围远程服务器。然而，在二十世纪九十年代，恰恰是由于网络的开放性威胁到了商业的安全性。由此，人们开始寻求可以安全交换私人信息的方法和途径。网络服务也是如此，并承诺将允许在全球范围进行点对点通信而不用管双方采用的是何种底层系统架构。为了实现这一目标，人们开发了WSS（Web Services Security）SOAP（Simple Objective Access Protocol）消息标准。

　　WSS为三种类型的SOAP消息安全提供了一个架构。它允许你：

1. 利用数字签名保护消息的完整性，确保原始XML不受更改
2. 通过对全部或部分SOAP消息加密确保不泄露信息机密
3. 运行验证过程对服务请求者进行校验。请注意，WSS标准支持多种验证，如X. 509、Kerberos和basic

　　CICS支持所有三种WSS对象。对于验证，CICS提供了basic和X. 509。

　　WSS验证的CICS支持

　　正如你所知，CICS网络服务支持包括了一个消息管道（message pipeline）的概念。一个消息管道由一系列程序组成，由CICS调用这些程序来处理入站（inbound）或出站（outbound）的SOAP消息。每个消息处理程序（message processor）可以提取或插入XML。

　　WSS标准为验证指定了合适的XML标签。对CICS而言，只需创建消息处理函数（message handler）来管理这些XML标签就可以了。对于入站消息，消息处理函数必须要能够从SOAP Header中检索验证消息并确认。对于服务请求，消息处理函数当然还必须在Header中插入安全内容（security context）。

　　CICS Web Service操作手册说明了写自己的消息处理函数的一些要求。不过，如果使用IBM提供的用于安全性的消息处理函数可能会更加简单一些，如DFHWSSE1。这个工具可以为你完成这个工作。

　　DFHWSSE1可以处理basic和X.509验证。在SOAP Header中basic验证使用的是用户口令，口令通常由用户ID和密码组成。DFHWSSE1检索登陆ID和密码后，与外部安全管理器确认信息，如RACF（资源访问控制设备）。如果验证通过，消息则会传送到下一个消息处理函数。反之，DFHWSSE1则告诉CICS返回SOAP错误。

　　至于X.509，你可能已经猜到，它要更复杂一些。对于入站消息，你必须先输入请求者的验证信息到RACF，作为一个ICSF （Integrated Cryptographic Service Facility ）密钥。然后，通过RACF RACDCERT(RACDigitalCertificate)命令重新连接输入的证书到keyring。对于CICS的使用，证书的keyring一定要与SIT（System Initialization Table）中指定的KEYRING参数相匹配。还要注意，RACDCERT可能会将登陆ID连接到该证书。CICS会把这个ID当作Web服务处理的安全内容（Security context）。如果用户ID不是通过RACDCERT连接的，CICS会使用keyring的默认ID。

　　相似地，如果要标记出站消息，你需要在RACF中生成一个证书并将它与SIT keyring相关联。然后，输入该证书到服务提供者的服务器。

　　提供证书之后，更改管道配置文件。你可以在包含自定义消息处理函数的部分指定验证选项。对于DFHWSSE1，特殊之处位于这部分的标签之间。在选项之间是：

1. 一个说明验证类型的部分。这部分还应该包含DFHWSSE1证书标签。
2. 是否标记入站消息以保证消息的完整性（）
3. 标记消息内容所使用的算法和证书。（）

　　如果这些都完成到位，DFHWSSE1自己会知道做什么，而且不用更改应用也可以执行网络服务安全性。更好的是，安全性处于系统级，不受程序员控制。

　　请注意，DFHWSSE1还可以用于消息加密，并且可以通过管道配置文件控制。在这种情况下，XML必须指定编码算法和使用的证书或key。CICS可以解密整个或部分SOAP body。唯一的出站选项是整体进行加密。加密和解密消息处理函数在消息管道中必须位于最开始或最末端。这样做是有道理的，入站XML只有经过解密才能被处理。不过，对于将会被随后的处理函数更改的数据加密就没什么意义了。

　　幸好，CICS决定支持WSS标准。证书的应用使其安全性比那些采取回避策略（如清除文本登陆ID和密码）的协议的安全性要高一些。同以往一样，你所选择的安全强度和安全类型依然取决于规范要求和通信系统的可靠性。