在本文中，我们将解释如何为 DB2 Web 服务提供者应用程序启用安全性，这包括启用认证、设置授权和确保消息是加密的。我们还将解释 Web 服务用户是如何被映射到数据库用户的。
IBM ®DB2 ®Web 服务提供者(或者 WORF —— Web 服务对象运行时框架)允许我们容易地将数据库数据和存储过程暴露为 Web 服务。这需要用户编写包含构成 Web 服务事务的数据库操作的 XML 文件。这些操作可以是 SELECT 语句、INSERT/UPDATE/DELETE 语句、存储过程以及 XML Extender 操作。本文描述如何约束用户访问这些可以更新或者获取数据库数据的操作。
什么是 Web 服务?
Web 服务是一个面向消息的通信框架，它被设计为具有高度的互操作性和可扩展性。
消息是以 XML 格式进行交换并且通过 SOAP(简单对象访问协议)进行描述的。SOAP 消息由一个包括头和主体的信封组成。头包括一些关于消息的元数据，它可以是一个事务 ID 或者加密密钥。主体包括实际的消息，它可以是一个订单或者保险报价。
Web 服务提供者的实际接口是通过 Web 服务描述语言(Web Service Description Language，WSDL)描述的。这非常类似于 C 编程语言中的头文件。WSDL 告诉用户一个 Web 服务提供者理解的操作，以及该操作的 输入和 输出是什么。WSDL 还包括新的特定于 Web 服务的类型定义。
理解了 WSDL 之后，用户就可以为 SOAP 请求消息创建 XML 了。用户还知道期望来自 SOAP 响应的 XML 是什么。通常，有一些工具用于构建 SOAP 请求以及从 SOAP 响应提取数据。可能使用的工具包括 WebSphere ®Studio 和 Microsoft ®Visual Studio .NET。请参阅参考资料中的一篇解释如何与 Visual Studio .NET 一起使用 DB2 Web 服务提供者的文章。
通常，SOAP 消息是通过 HTTP 发送的，但是还可能存在其他种类的传输，例如 WebSphere MQ。
由于 HTTP 和 XML 等标准的广泛使用，所以 Web 服务具有很强的互操作性。服务器端和客户端可以使用不同的操作系统、应用服务器和开发工具。访问 Web 服务并不需要安装像数据库驱动程序这样的客户机代码。
DB2 Web 服务提供者
DB2 Web 服务提供者是 Java ™应用服务器(比如 WebSphere Application Server 和 Jakarta Tomcat)的一个扩展。Web 服务提供者将允许您在 XML 文件中编写数据库操作并且将这些操作转换为一个 Web 服务。这种 XML 文件的一个示例是 DADX(文档访问定义扩展)文件，它看起来类似于：
清单 1. 一个简单的 DADX 文件
＜?xml version="1.0"?＞
＜DADX xmlns="http://schemas.ibm.com/db2/dxx/dadx" xmlns:xsd="http://www.w3.org/2001/XMLSchema"＞
＜documentation＞List contents of DEPARTMENT table.＜/documentation＞
＜operation name="listDepartments"＞
＜documentation＞Lists each department.＜/documentation＞
＜query＞
＜SQL_query＞SELECT * FROM DEPARTMENT WHERE deptno=:deptno＜/SQL_query＞
＜parameter name="deptno" type="xsd:string" kind="in" /＞
＜/query＞
＜/operation＞
＜/DADX＞
Web 服务提供者运行时在运行时做下列事情：
由于用户只需要编写 DADX 文件，因此并不需要理解 WSDL 规范。一个适度复杂的 DADX 的 WSDL 长度可能有许多页。运行时将确定一个 SQL 操作的参数(比如本例中的 deptno)并且还分析该 SQL 结果集的元数据，以创建正确的 XML 输出类型。
用户将完成下列步骤，以创建一个 DADX 应用程序：
DADX 中的查询是作为一个实现工作的，因为运行时执行查询并将结果格式化为 XML。这意味着用户不需要用编程语言编写代码并理解 Web 服务引擎的编程模型。如果用户自己希望为 WebSphere 编写 Web 服务，他将需要编写 Java 代码或者 Enterprise Java Bean(EJB)来调用 SQL。
用于访问测试环境的 URL 包括 DADX 名称(例如，list.dadx)以及其他部分。其中一个部分是“services”，它是 DADX 所在的 Web 应用程序的 名称或者 上下文根。另一个部分(mydatabase)是一个 组名称。组是 Web 应用程序中的 DADX 文件的容器。组之间相互共享配置设置，比如用于连接数据库的数据库用户。在后面，我们将看到如果配置数据库用户。
安全性方面
Web 应用程序或者 Web 服务应用程序的安全性由许多部分组成。其中许多安全性方面对于数据库管理员是已知的。本节解释在 WebSphere 中这是如何工作的。这里我们关注的事情是：
识别意味着告诉该服务您是谁。例如，您可以作为用户“dirk”进行连接。当然，如果没有 认证，这就没有太多的意义。通过认证，您提供一个证明，表示您的确就是所声称的那个人。这个证明可以是一个口令或者某种安全令牌。这对于使用“CONNECT TO sample USER dirk USING mypassword”SQL 命令的用户来说是熟悉的。
授权负责为用户允许或者拒绝特定的事情。在数据库系统中，这是通过“GRANT”语句完成的。我们将解释在 Web 服务上下文中，用户是如何做类似“GRANT SELECT, INSERT ON CALENDAR TO USER PHIL”的事情的。
完整性是一种确保消息没有被篡改的方法。通过使用 机密性，我们可以确保没有人能够读取在非安全的通信隧道上传输的消息。确保机密性的一个例子是使用加密。
Web 服务安全性
您可以通过以下两种方式获得 Web 服务安全性：
传输级安全性意味着安全机制是通过传输所提供的方法获得的。例如，您可以通过使用 HTTPS(安全 HTTP)获得机密性。HTTPS 将加密所有被交换的 HTTP 消息。如果 Web 服务切换到另一个传输，比如不具有加密通信隧道的非安全的 HTTP，那么消息将再次以明文传输。
本文解释如何为 DB2 Web 服务提供者设置传输级安全性。虽然还没有介绍消息级安全性，但是我们先来看看这个特性。
由于您还希望非安全传输上的安全性，因此需要使用 消息级安全机制，比如 WS-Security。WS-Security 允许用户使用多种安全性元素，比如用户名、签名和加密机制以及安全令牌。与传输级安全性相比，WS-Security 允许用户只是加密消息的一部分(例如，信用卡号码)而不是加密客户机和服务器之间的完整通信。它还允许不同的识别和认证机制。
图 1. WS Security 路线图
如图 1 所示，WS-Security 是一个 Web 服务安全性标准，其他的 Web 服务安全性标准构建在它的上面。IBM 和 Microsoft 发布了 WS Security 的这个路线图(请参阅参考资料小节)。其他的标准简要描述如下：
WS-Policy：描述中间点和端点上的安全策略(或者其他商业策略)的能力和约束(例如，所需的安全令牌，所支持的加密算法，隐私权规则)。
WS-Trust：描述使 Web 服务能够安全地进行互操作的信任模型的框架。
WS-Privacy：描述 Web 服务提供者和请求者如何声明主题隐私权首选项和组织隐私权实践声明的模型。
WS-SecureConversation：描述如何管理和认证各方之间的消息交换，包括安全上下文交换以及建立和继承会话密钥。
WS-Federation：描述在异构的联合环境中如何管理和代理信任关系，包括支持联合的身份。
WS-Authorization：描述如何管理授权数据和授权策略。
在下一节中，我们讨论 DB2 Web 服务提供者安全性所引起的问题，并展示如何在 WebSphere 中解决这些问题。