DB2 Web 服务提供者的安全性

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Dirk Wollscheid (wollsch@us.ibm.com), 咨询软件工程师, IBM　

2004 年 7 月 01 日

在本文中，我们将解释如何为 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（文档访问定义扩展）文件，它看起来类似于：

<?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 文件创建 WDSL。
• 从 DADX 创建一个基于浏览器的测试环境。
• 使用 DADX 文件作为 Web 服务的实现。

由于用户只需要编写 DADX 文件，因此并不需要理解 WSDL 规范。一个适度复杂的 DADX 的 WSDL 长度可能有许多页。运行时将确定一个 SQL 操作的参数（比如本例中的 deptno）并且还分析该 SQL 结果集的元数据，以创建正确的 XML 输出类型。

用户将完成下列步骤，以创建一个 DADX 应用程序：

• 创建一个 DADX 文件。
• 创建和部署一个 Web 应用程序。
• 访问基于浏览器的测试环境，例如，http://localhost:9080/services/sample/list.dadx/TEST。
• 修改 Web 应用程序中的 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 是一个 Web 服务安全性标准，其他的 Web 服务安全性标准构建在它的上面。IBM 和 Microsoft 发布了 WS Security 的这个路线图（请参阅参考资料小节）。其他的标准简要描述如下：

• WS-Policy：描述中间点和端点上的安全策略（或者其他商业策略）的能力和约束（例如，所需的安全令牌，所支持的加密算法，隐私权规则）。
• WS-Trust：描述使 Web 服务能够安全地进行互操作的信任模型的框架。
• WS-Privacy：描述 Web 服务提供者和请求者如何声明主题隐私权首选项和组织隐私权实践声明的模型。
• WS-SecureConversation：描述如何管理和认证各方之间的消息交换，包括安全上下文交换以及建立和继承会话密钥。
• WS-Federation：描述在异构的联合环境中如何管理和代理信任关系，包括支持联合的身份。
• WS-Authorization：描述如何管理授权数据和授权策略。

在下一节中，我们讨论 DB2 Web 服务提供者安全性所引起的问题，并展示如何在 WebSphere 中解决这些问题。

回页首

在 WebSphere 中实现 Web 服务安全性

DB2 Web 服务提供者的安全性问题

为 DB2 Web 服务提供者设置安全性的管理员的问题是识别和认证的问题，这个我们已经提到过。我们将要求用户通过 HTTP 认证进行客户认证来解决该问题。HTTP 认证意味着 HTTP 请求必须具有一个带有用户标识和口令的 HTTP 头字段。当您在浏览器中遇到一个要求认证的 Web 页面时，您通常得到一个对话框，让您为该 Web 页面输入您的用户标识和口令。在 SOAP 情况下，必须修改客户机程序以发送用户标识和口令。

我们通过对 URL 使用 J2EE（Java 企业版）授权机制来解决授权问题。由于所有的 Web 服务请求都基于发送消息到特定的 URL，我们可以配置 Web 应用程序使得只有特定的用户可以发送请求给特定 URL。URL 可以是一个 DADX，或者是一组完整的 DADX 文件。我们将在后面详细讨论。

机密性和完整性可以通过要求用户使用 HTTPS 来简单地得到解决。这意味着所有网络传输都是加密的，并且消息篡改也可以检测到。

这里还有最后一个问题，就是将利用 WebSphere 认证的用户映射到执行 DADX 中的语句的数据库用户。由于我们的运行时不能确定在 HTTP 认证中所使用的用户标识和口令，因此我们不能使用该用户连接到数据库。在某些情况下，如果应用服务器用户不同于数据库用户，这甚至是不现实的。这种情况的一个例子是应用服务器和数据库服务器运行在不同的机器上并且都使用操作系统作为用户注册表。相反，您可以在组（包含多个 DADX 文件）上指定一个用户标识和口令。该用户将被用于执行组中的 DADX 中的所有 SQL 语句。如果希望区分执行 SQL 的用户，您可以创建单独的组，比如针对会计部门的用户创建一个组，针对工程部门的用户创建一个组。

准备工作

对于下面的步骤，我们假定您已经按照安装所推荐的，从 DB2 V8 安装中的 sqllib\samples\java\Websphere 目录下，将 dxxworf.zip 解压到 c:\worf。您还需要遵循安装指令。您不需要安装示例 Web 应用程序 services.war，因为我们在下面的步骤中将要修改它。如果已经部署 services.war，这是可以接受的，因为我们将要把该示例 war 部署为一个不同的 Web 应用程序。

我们将使用应用服务器工具集（Application Server Toolkit，ASTK）来修改示例 war 文件，以增加安全性约束。ASTK 非常类似于 WebSphere Studio，因此如果用户喜欢用 WebSphere Studio ，也能达到同样的效果。第一步是将示例 war 文件导入到 ASTK 中。图 2 中描述了这一步。

输入您希望添加安全性约束的 war 文件的位置。

我们创建一个名为“SecureDADX”的新的 Web 应用程序，该应用程序将包括 DADX 文件和其他配置文件。

同时，还将示例 war 文件从符合 J2EE 1.2 迁移到符合 J2EE 1.3。选择 SecureDADXWeb 模块，右击并选择 Migrate和 J2EE Migration wizard。这允许我们在后面使用 WebSphere 5 DataSource。

我们已经导入 Web 应用程序，现在可以针对安全性对它进行修改了。下一步是在 war 文件中设置数据库连接。

设置数据库用户

针对完整的 DADX 文件组，配置数据库用户。您可以以明文形式或 base64 编码的形式在叫做 group.properties 的配置文件中输入用户标识和口令，来设置数据库用户。但是即使利用编码，这并不提供真实的安全性，因为口令并没有被加密。补救措施是设置 Web 服务提供者使用一个数据源（DataSource），然后在 WebSphere 中为该数据源设置用户。该方法的另一个优点是您可以对于多个数据源使用连接池。

在下一步中，为 dxx_sample 组打开组配置文件，如图 5 所示。您可以切换到位于窗口左中部的“Project Navigator”视图来查看该项目中的所有文件。到该文件的路径是“SecureDADX/Java Resources/groups.dxx_sample/group.properties”。修改前面两个配置参数为：

initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactory

datasourceJNDI=jdbc/sampleDataSource

第一个参数“initialContextFactory”是在 WebSphere 中访问 JNDI（Java 命名和目录接口）所需要的。第二个参数“datasourceJNDI”是 JNDI 中数据源的名称。后面，我们将在 WebSphere 中用这个名称配置数据源。

在下一步中，当我们利用 WebSphere 管理控制台工作时，将在 WebSphere 中完成数据源的设置。

设置授权

下面的步骤修改您的 Web 应用程序的部署描述符。单击位于窗口左下侧的 J2EE Hiearchy标签，然后双击 Web 应用程序 SecureDADX，如图 6 所示。这将打开 Web 应用程序部署描述符编辑器。单击 Security 标签，以编辑安全性设置。

下一步创建一个新的角色。角色是用户的集合，它类似于操作系统中的组。在该示例中，我们创建一个角色 —— “DADXUser”，以包含所有允许访问 DADX 的用户。在一个真实的应用程序中，您可能创建诸如 “accounting”、“engineering” 和 “administrator” 的角色，然后允许它们访问不同的 DADX 文件。

在创建角色之后，单击编辑器中的 Security constraints 标签。安全性约束类似于数据库中的“GRANT”语句。不同之处在于它们处理的是 URL，而不是表、存储过程和其他数据库对象。我们为完整的 DADX 组创建一个安全性约束。这就是 URL 模式表示为“/db2sample/*”的原因，这是针对 dxx_sample 组中的所有 URL 的 URL 路径（注意：在 web.xml 部署描述符文件中存在一个从 dxx_sample 到 db2sample URL 的映射）。

如果您希望以相同的约束增强整个 Web 应用程序的安全性，可以使用 URL 模式的其他选项，比如“/*”。或者，如果您希望以这个安全性约束增强一个特定 DADX 的安全性，可以使用 /db2sample/myDADX.dadx/*。您可以具有多种安全性约束，因此有可能将所有的读操作放在一个 DADX 文件中，而将写操作放在另一个 DADX 中，然后要求用户在特定的角色中，以允许执行读取或者更新操作。

接下来的三个图展示如何添加安全性约束（图 8），如何设置正确的 URL 和 HTTP 方法（图 9）以及如何针对该约束允许“DADXUser”角色（图 10）。

下一步是为我们的 Web 应用程序设置机密性。

HTTPS 通信

在“User Data Constraints”部分，您可以将类型设置为“Confidential”。这意味着所有的通信将通过 HTTPS 完成。这将确保没有人能够读取通过公共网络发送的消息。

最后一步是，每当用户引用我们 Web 应用程序中的 Web 页面、WSDL 和 Web 服务时，就要求用户进行认证。

URL 认证

在 Web 应用程序部署描述符编辑器中，单击“Pages”标签并设置认证类型为 Basic。这意味着 Web 服务客户机或者 Web 浏览器需要在 HTTP 头中提供一个用户标识和口令。

在最后这些步骤中，我们通过双击“DefaultEAR”打开企业应用程序部署描述符，如图 13 所示。

在 EAR 部署描述符编辑器中，我们首先从 Web 应用程序或者它所包含的 war 文件中“收集”安全角色（图 14）。然后我们通过在角色列表中选择“DADXUser”来增加一个用户到该角色（图 15），然后在“Users/Groups”之下单击“Add”按钮。还可能通过这种方式将一组用户加入到一个角色中。注意，如果该 EAR 被部署到多个机器上，其中用户并不一定是相同的，您仍然可以在部署时改变角色到用户或组的映射。

我们已经在 ASTK 中完成了 EAR 设置。剩下的一个步骤就是保存 EAR 部署描述符，以及为在 WebSphere中进行部署而将该 EAR 文件导出到文件系统。

应用程序设置已经基本完成了。我们还需要在 WebSphere 中配置安全性，部署我们的应用程序，然后测试它。

WAS 设置

您可以使用 WebSphere 管理控制台来配置 WebSphere，它是一个基于浏览器的工具。如果您是以默认方式安装了 WebSphere，那么它的位置是 http://localhost:9090/admin/。我们将启用安全性，完成 DataSource 设置并且最终部署我们所创建的 EAR。如果您是在 WebSphere 安装中做这些工作，那么使用 backupConfig 工具来备份旧的工作配置是一个好主意。关于该工具的信息请参见您的 WebSphere 文档。

第一步是在 WebSphere 中打开安全性。这将使得 WebSphere 在 Web 应用程序中强制实施所有的安全性约束。导航至 Security -> User Registries -> Local OS 页面。提供一个用户标识和口令，WebSphere 可以用它们来连接到用户注册表。默认的用户注册表是操作系统，但是 WebSphere 还支持 LDAP 和用户注册表。

接着，导航至 Security -> Global Security部分，并且选中 Enabled 复选框，如图 19 所示。请确保“Enforece Java 2 Security”是未被启用的。如果它被启用的话，我们将需要利用它所允许访问的文件（例如所有的 DADX 文件）来配置 Java 虚拟机安全配置文件。还要确保“User registry”是默认值（“Local OS”），否则这些指令将不能工作。

单击 Apply and Save to Master 配置。 打开安全性需要重新启动 WebSphere。假设在 PATH 中具有 WebSphere 目录，您可以在命令行执行这些命令：

stopserver server1 -username wollsch -password mypasswd

startserver server1 -username wollsch -password mypasswd

重新启动之后，打开 WebSphere 管理控制台。如果安全性设置是成功的，现在当您进入 WAS 管理控制台的时候，必须输入用户标识和口令。

导航至 Security -> JAAS Configuration -> J2C Authentication Data部分并单击 New。这将引导您进入一个页面，如图 20 所示。这个用户标识将用于连接到作为我们的数据源的数据库。

导航至 Resources -> JDBC provider部分，单击 New并选择 DB2 Legacy CLI-based Type 2 JDBC driver。输入 db2java.zip JDBC 驱动程序文件的位置，如图 21 所示。使用 “Universal JDBC driver” 或者 JCC JDBC 驱动程序是另外的选项，由于它意味着更多的配置，因此我们没有选择使用。

为了创建数据源，导航至 Resources -> JDBC provider部分并选择您所创建的 DB2 Legacy CLI-based Type 2 JDBC driver，单击 Datasource然后单击 New。这将把您引导至两个对话框，如图 21 和 22 所示。您必须提供一个名称（ sampleDataSource）和一个 JNDI 名称（ jdbc/sampleDataSource），如图 21 所示。JNDI 名称必须与您在 war 文件中指定的名称相匹配。图 22 显示如何将 JAAS 用户与数据源相联系。所有的连接都将通过该用户进行创建。

在创建连接之后，测试该连接，如图 24 所示。这将确保您已输入所有正确的数据库和用户信息。如果数据源连接测试或者在调用 DADX Web 服务时发生某些失败，打开 WebSphere 错误日志，也就是打开 logs\server1\SystemErr.log 或者 SystemOut.log 文件，具体位置取决于您是在哪里安装 WebSphere 的。

在 WebSphere 管理控制台中的最后一步是部署我们已经创建的 EAR 文件。图 24 显示如何指定 EAR 文件的位置。在下面这些页面中，您可以使用所有的默认值，或者如果用户在目标机器上是不同的，则修改角色到用户的映射。

为了启动已经部署的应用程序，导航至 Applications -> Enterprise Applications部分，选择您的应用程序（ DefaultEAR）并且选择 Start。

创建 Web 服务客户机

在创建客户机之前，您可以使用内建的浏览器测试环境来测试已经部署的应用程序。通过 Web 浏览器访问 http://localhost:9080/SecureDADX/index.html。您可能会得到一个错误消息，表示来自服务器的证书是无效的。这是因为 WebSphere 只是带有一个自己签署的证书，浏览器不能验证它是否正确。您可以从签名授权机构获得一个官方的证书，或者忽略该消息。试用 list.dadx，并检查您能否以允许访问 Web 服务的用户身份进行连接，同时还应该尝试不允许访问 Web 服务的身份。

在编写客户机程序时，必须确保在调用安全的 Web 服务时客户会提供用户标识和口令。取决于您所使用的 API 和编程环境，工作方式可能会不同，必须参考您的文档。

如果您希望通过 JAX-RPC（Java API for XML-Based RPC）调用安全的 Web 服务，可以遵循指示和使用 Sun 的 JAX-RPC 指南（ http://java.sun.com/webservices/docs/1.0/tutorial/doc/JAXRPC.html）中的示例代码。请参见 “Security for JAX-RPC” 章节。

致谢 作者希望感谢 Ellen Patterson、Michael Schenker 和 Joel Rolfe，感谢他们对本文的帮助和反馈。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• DB2 信息中心 DB2 Information Center
  
  
• DB2 developeworks Web 服务专区 DB2 developeworks Web 服务专区
  
  
• WebSphere 5 安全红皮书 WebSphere 5 security redbook
  
  
• WS-Security 规范 WS-Security spec
  
  
• WS-Security 路线图 WS-Security roadmap
  
  
• 创建使用 DB2 DADX Web 服务的 .NET 客户机 http://www.ibm.com/developerworks/cn/dmdd/library/techarticles/0212yu/0212yu.shtml
  
  
• 利用 Web 服务访问 DB2 https://www6.software.ibm.com/reg/devworks/dw-db2wsw5-i?S_TACT=103AMW11&S_CMP=;DB2DD。
  

关于作者

		Dirk Wollscheid 是位于圣何塞的 IBM 硅谷实验室 DB2 应用集成和 Web 服务小组的一名咨询软件工程师。他是信息集成 Web 服务开发方面的技术主管。他感兴趣的领域是 DB2、应用服务器、XML 以及 Web 服务。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首