第 1 部分: HTTPS、.NET 和 UsernameToken  


级别: 初级

Tony Cowan, 高级 IT 专家, IBM


2005 年 4 月 13 日

该教程包括两个部分，在第 1 部分中，您将了解如何使用 IBM® Websphere® Studio Application Developer V5.1.2（以下称为 Application Developer）保护使用传输级安全性 (HTTPS) 的 Web 服务，以及如何从 Java™ 2 Extended Edition (J2EE)、Java 2 Standard Edition (J2SE) 和 .Net 客户机中对其进行访问。然后我们将在 Web 服务安全性头中添加 UsernameToken、数字签名和加密并从 J2EE 客户机中调用它们。

示例场景概述
在该教程中，我们将了解如何在 Application Developer 和 Application Server 中配置 Web 服务安全性。我们将配置传输级安全性和 Web 服务安全性。我们的示例场景包括三个客户机和一个服务器，如图 1 所示。
图 1. 示例场景

首先，您需要在 Application Developer 中创建下面的 Java 项目：

• EchoService——一个包含 EJB 模块 (EchoServiceEJB) 的企业应用程序，该模块包括示例服务 (EchoService) 的实现和一个 Web 模块 (EchoServiceWeb)，而 Web 模块承载服务 HTTP 端点并在 EJB 模块中向实现转发请求。
  
• EchoServiceClient——一个包含 Web 模块 (EchoServiceClientWeb) 的企业应用程序，该 Web 模块包含作为 EchoService 的客户机的 Servlet (TestServlet)。
  
• EchoServiceJ2SEClient——一个单机版 Java 应用程序项目，该项目包含作为 EchoService 的客户机的 Java 应用程序 (TestClient)。
  
• EchoServiceClient.exe——一个 .Net EchoService 客户机，它是在安装有.Net framework Version 1.1 和 Microsoft Web Services Enhancements V2.0 的 Microsoft™ Windows™ 2000 之上构建的。

PKI 密钥和证书
我们将在两个级别中使用 PKI 密钥和证书。首先，我们将使用 SSL 保护 HTTP 传输，这里需要证书。其次，客户机将与使用 Web 服务和 Web 服务安全性（包含 XML 签名以及 XML 加密元素）的服务器进行交互，因此这里同样需要证书。

传输安全性 (SSL)
示例场景中的三个客户机都使用 SSL 传输安全性。Servlet 和 Java 2 Standard Edition 客户机使用双向验证的 SSL，而 .Net 客户机只使用服务器身份验证。

Web 服务安全性
只有基于 Servlet 的客户机，TestServlet，具有 Web 服务安全性。我们将为该客户机配置 XML 数字签名、XML 加密以及 UsernameToken。

先决条件
要完成该教程，您需要下面的工具：

• 具备 V5.1 WebSphere Test Environment 的 Application Developer V5.1.2。
  
• 如果希望使用该教程附带的 .Net 客户机，您还需要一台安装了 .Net framework V1.1 的 Windows 计算机（2000 或者 XP）。

需要具备以下知识：

• 熟悉如何使用 Application Developer V5.1.2 构建 Web 服务。
  
• 理解安全性的概念和术语。
  
• 熟悉如何使用 Application Developer 保护 Web 应用程序。

入门
创建本教程使用的全部项目所需的 Application Developer V5.1.2 项目交换文件称为 WSS5.1.zip，它包含在下载部分附带的 wssecurity1.zip 文件中。

• 选择 Start => Programs => WebSphere Studio => Application Developer，启动 Application Developer。
  
• 通过将名称 L10 添加到缺省名称，创建一个新工作区。
  
• 将 EchoService 和客户机导入到该工作区，如下所示：
  ·选择 File => Import => Project Interchange。
  ·浏览到 /WTE2004/WSSecurity 文件夹。
  ·选择 WTE2004WSLabs.zip。
  
• 生成 EJB Deploy 和 RMIC 代码，如下所示：
  ·在 EJB Modules 下面，选择 EchoServiceEJB 项目。
  ·右键单击该项目，选择 Generate => Deploy and RMIC Code。
  ·选择 EchoService，然后单击 Finish。
  
• 通过执行以下操作，验证测试服务器是否正常启动：
  ·打开服务器透视图 (Server perspective)。
  ·选择 Servers 选项卡。
  ·右键单击 WebSphere v5.1 Test Environment 服务器，然后选择 Start。如果应用服务器正常启动，您应该在控制台窗口看到下面的信息：

  引用:

  *** Starting the server ***
  ************ Start Display Current Environment ************
  WebSphere Platform 5.1 [BASE 5.1.0.3 cf30412.02] [JDK 1.4.1 b0344.02]  running with
          process name localhost\\localhost\\server1 and process id 3988
  Host Operating System is Windows XP, version 5.1
  Java version = J2RE 1.4.1 IBM Windows 32 build cn1411-20031011 (JIT enabled: jitc),
          Java Compiler = jitc, Java VM name = Classic VM
  was.install.root = d:\\IBM\\WebSphere Studio\\Application Developer\\v5.1.2\\runtimes\\base_v51
  user.install.root = d:\\IBM\\WebSphere Studio\\Application Developer\\v5.1.2\\runtimes\\base_v51
  Java Home = d:\\IBM\\WebSphere Studio\\Application Developer\\v5.1.2\\runtimes\\base_v51\\java\\jre
  ws.ext.dirs = d:\\IBM\\WebSphere Studio\\Application
                  .......
  [10/3/04 12:48:35:350 EDT] 3cc0110b ApplicationMg A WSVR0200I: Starting application: EchoService
  [10/3/04 12:48:35:370 EDT] 3cc0110b EJBContainerI I WSVR0207I: Preparing to start EJB jar: EchoServiceEJB.jar
  [10/3/04 12:48:37:833 EDT] 3cc0110b EJBContainerI I WSVR0037I: Starting EJB jar: EchoServiceEJB.jar
  [10/3/04 12:48:37:954 EDT] 3cc0110b WebContainer  A SRVE0169I: Loading Web Module: EchoServiceWeb.
  [10/3/04 12:48:37:994 EDT] 3cc0110b WebGroup      
          I SRVE0180I: [EchoServiceWeb] [/EchoServiceWeb] [Servlet.LOG]: JSP 1.2 Processor: init
  [10/3/04 12:48:38:074 EDT] 3cc0110b WebGroup      
          I SRVE0180I: [EchoServiceWeb] [/EchoServiceWeb] [Servlet.LOG]: SimpleFileServlet: init
  [10/3/04 12:48:38:084 EDT] 3cc0110b WebGroup      
          I SRVE0180I: [EchoServiceWeb] [/EchoServiceWeb] [Servlet.LOG]: InvokerServlet: init
  [10/3/04 12:48:38:915 EDT] 3cc0110b ApplicationMg A WSVR0221I: Application started: EchoService
  [10/3/04 12:48:38:915 EDT] 3cc0110b ApplicationMg A WSVR0200I: Starting application: EchoServiceClient
  [10/3/04 12:48:39:145 EDT] 3cc0110b WebContainer  A SRVE0169I: Loading Web Module: EchoServiceClientWeb.
  [10/3/04 12:48:39:195 EDT] 3cc0110b WebGroup      
          I SRVE0180I: [EchoServiceClientWeb] [/EchoServiceClientWeb] [Servlet.LOG]: JSP 1.2 Processor: init
  [10/3/04 12:48:39:205 EDT] 3cc0110b WebGroup      
          I SRVE0180I: [EchoServiceClientWeb] [/EchoServiceClientWeb] [Servlet.LOG]: SimpleFileServlet: init
  [10/3/04 12:48:39:215 EDT] 3cc0110b WebGroup      
          I SRVE0180I: [EchoServiceClientWeb] [/EchoServiceClientWeb] [Servlet.LOG]: InvokerServlet: init
  [10/3/04 12:48:39:226 EDT] 3cc0110b ApplicationMg A WSVR0221I: Application started: EchoServiceClient
  [10/3/04 12:48:39:296 EDT] 3cc0110b HttpTransport A SRVE0171I: Transport http is listening on port 9,080.
  [10/3/04 12:48:40:668 EDT] 3cc0110b HttpTransport A SRVE0171I: Transport https is listening on port 9,443.
  [10/3/04 12:48:40:708 EDT] 3cc0110b RMIConnectorC A ADMC0026I: RMI Connector available at port 2809
  [10/3/04 12:48:40:738 EDT] 3cc0110b WsServer      A WSVR0001I: Server server1 open for e-business

创建密钥存储
这一部分描述了创建密钥存储和密钥所必需的步骤，以便将 Application Server 用于测试。没有介绍生产环境中常见的发出证书请求的实践。
Application Server 提供了操作密钥存储的两个工具：

• iKeyman 提供了使用密钥存储的图形界面，这可能更适合于新用户。但 iKeyman 有一个局限性，它不允许用户指定每一个密钥的密码。它为存储中的所有密钥设置的密钥密码与密钥存储密码相同。
  
• keytool 是 Java 开发工具包 (JDK) 所附带的，它提供一个命令行界面。对大多数应用程序来说，这是首选项，因为它可以通过编写脚本来实现。

由于 keytool 具有更大的灵活性，它允许密钥密码独立于密钥存储密码进行配置，并且它可以通过编写脚本来实现，因此在该教程中我们将使用 keytool 创建密钥。
请注意，虽然两个工具都允许用户生成自签署的证书，但是它们都不允许用户签署证书。使用某个受信任的认证中心密钥签署证书的功能需要最复杂的 PKI 安装，这表明为了实现此目的，任何部署 PKI 技术的组织都应该研究成熟的工具。Application Server 附带的工具适用于小型安装和测试的目的。

制订密钥要求
这一经常忽视的步骤可以帮助避免混淆和失败，而它们往往以安全性专家的昂贵访问而告终。花几分钟的时间从逻辑上拟定系统，这些系统将通信并指示它们需要哪些密钥，这些密钥存储在哪些密钥存储中。图 2 显示了密钥存储的一个可能的布局。在该图中，Echo Service 寄宿在 Application Server 中。
图 2. 密钥存储布局示例

创建密钥存储
为 SSL/TLS 生成密钥
当生成使用传输安全性的密钥时，会出现两个问题。第一个问题是，颁发给服务器的证书中专有名称 (DN) 的通用名称 (CN) 组件应该是服务器的域名。第二个问题是，如果使用客户机证书，客户机证书中的 DN 可能必须映射到服务器使用的用户注册表中的一个真正的用户。可以将 Application Server 配置为只检查客户机证书是否由受信任的认证中心颁发，但是也可以配置为根据客户机证书中的 DN 建立安全上下文。在后面的示例中，客户机证书必须包含 Application Server 领域的一个有效的用户 DN。
对于双向 SSL，我们需要客户机密钥和服务器密钥。

• 客户端需要考虑的事项：要建立 Application Server 安全上下文，我们不使用用于建立 SSL 会话的客户机证书，因此我们不需要考虑颁发一个其 DN 与 Application Server 用户注册表中的 DN 相匹配的客户机证书。然而，我们需要将客户机配置为信任签署服务器的公钥证书的认证中心 (CA)。在我们的示例中，由于服务器的证书是自签署的，我们需要将服务器的公钥证书配置为客户机受信任的签署者。
  
• 服务器端需要考虑的事项：我们要将服务器配置为需要受信任的 CA 颁发的客户机证书。因为我们的客户机证书将是自签署的，所以我们需要将客户机的公钥证书配置为服务器受信任的签署者。同样，如上所述，按照约定，编写的客户机必须要求：用于识别服务器的证书（当建立 SSL 会话时，服务器提供给客户机的证书）具有的 CN 与客户机认为正在与其通信的主机的域名相同。这意味着，当客户机试图与 https://www.mydomain.com/ 建立 SSL 连接时，客户机必须要求：服务器提供给客户机的证书中的 CN 为 www.mydomain.com 。这是一个稍微简单的示例，可能会有更加复杂的场景，但它表示了实质问题。因此，我们需要决定客户机将使用哪一个URL 与服务器取得联系并使用其 CN 设置为服务器创建证书。为了使我们的场景变得简单，我们将在同一台计算机上运行所有的客户机和服务器，这样我们可以选择使用客户机使用的 URL 中的主机名 localhost 与服务器连接。因此，这意味着应该将我们的服务器证书的 CN 设置为 localhost。

按照约定，将密钥存储分为两类，一类包含私钥，一类包含公钥。后者一直包装在公钥证书中。我们在此处将遵循该约定，为每个客户机和服务器创建两个密钥存储。
有关下面使用的命令行选项的详细说明，请参阅 keytool 用户指南。
我们希望生成的这些密钥可以用于 Application Server 中。当为 Application Server 创建 SSL 配置时，您将注意到不能指定密钥别名或者密钥密码。从这里您可以看出，使用 SSL 的用于包含私钥的密钥存储应该只包含一个私钥（它可以包含其他的公钥证书）。您还可以看到，密钥密码必须设置为密钥存储密码。
下面的步骤描述了如何创建该练习中使用的密钥。您可以按照以下部分一个一个地进行练习，或者使用 wssecurity1.zip 文件中附带的 createKeyStores.cmd 命令文件。

创建密钥存储
为 SSL/TLS 生成密钥

设置 keytool

• 打开命令提示符，转到目录 c:\\WSSLabOne。
  
• 通过键入下面的命令，将包含 keytool 的目录添加到路径中：

  引用:

  set PATH=\\runtimes\\base_v51\\java\\jre\\bin\\;%PATH%

  其中  是 Application Server 的安装目录。例如：

  引用:

  d:\\IBM\\WebSphere Studio\\Application Developer\\V5.1.2

为 J2SE 和 J2EE 客户机创建密钥对和证书

• 要创建密钥对和自签署的公钥证书来表示 J2SE 和 J2EE 客户机，请转到命令提示符并在一行中键入下面的命令：

  引用:

  keytool -genkey -v -alias wasclient -keypass clientsslkeys -keystore clientsslkeys.jceks
          -storepass clientsslkeys -storetype jceks -dname \"cn=wasclient, o=ibm, c=us\" -keyalg \"RSA\"

  成功完成以后，您将看到以下信息：

  引用:

  Generating 1,024 bit RSA key pair and self-signed certificate (MD5WithRSA) for: CN=wasclient, O=ibm, C=us
  [Saving clientsslkeys.jceks]

  您还应该有一个称为 clientsslkeys.jceks 的文件。
  请注意，如果您要根据客户机证书中的标识在 Application Server 中建立安全上下文，您需要使用承载服务的 Application Server 使用的用户注册表中 keytool 命令的 DN。为此，您需要确定希望客户机表示的用户 DN，然后将该 DN 放在 -dname 选项后面的引号中。
  
• 要导出客户机公钥证书以将其导入到服务器信任存储中，请键入下面的命令：

  引用:

  keytool -export -v -alias wasclient -file wasclient.cert -rfc -keystore clientsslkeys.jceks
          -storepass clientsslkeys -storetype jceks

  成功完成该命令以后，您将看到以下信息：

  引用:

  Certificate stored in file

  现在您有了第二个文件，称为 wasclient.cert。
  

创建密钥存储
为 SSL/TLS 生成密钥

为服务器创建密钥对和证书

• 在一行中键入下面的命令创建密钥对和自签署的公钥证书，以表示 Application Server：

  引用:

  keytool -genkey -v -alias wasserver -keypass serversslkeys -keystore serversslkeys.jceks -storepass serversslkeys
          -storetype jceks -dname \"cn=localhost, o=ibm, c=us\" -keyalg \"RSA\"

  成功完成以后，您将看到以下信息：

  引用:

  Generating 1,024 bit RSA key pair and self-signed certificate (MD5WithRSA)
          for: CN=localhost, O=ibm, C=us
  [Saving serversslkeys.jceks]

  您应该有了一个称为 serversslkeys.jceks 的文件。
  请注意，如果访问服务器时 URL 中使用的主机名不是localhost，则需要修改上面的 DN 以反映这种情况。为此，您要确定希望客户机在 URL 中使用的服务器的主机名，然后将该字符串放在引号中的 DN 的 cn= 部分，位于 keytool 命令中 -dname 选项之后。上面的配置将为 URL 进行如下设置：

  引用:

  http://localhost/somepath

  。
  
• 通过键入下面的命令，导出服务器公钥证书以将其导入到客户机信任存储中：

  引用:

  keytool -export -v -alias wasserver -file wasserver.cert -rfc -keystore serversslkeys.jceks
          -storepass serversslkeys -storetype jceks

  该命令成功完成以后，您将看到以下信息：

  引用:

  Certificate stored in file

  现在您有了一个称为 wasserver.cert 的文件。
  

既然已经为客户机和服务器创建了密钥存储，我们需要为客户机和服务器创建信任存储来建立信任域。我们需要使用客户机中的服务器公钥证书来为客户机创建信任存储。在创建客户机信任存储之前，必须已经使用上面服务器部分中的命令创建服务器密钥存储并导出服务器公钥证书。

• 通过执行下面的命令，使用服务器公钥证书为客户机创建信任存储：

  引用:

  keytool -import -v -noprompt -alias wasserver -file wasserver.cert -keystore
          clientssltrusts.jceks -storepass clientssltrusts -storetype jceks

  完成之后，您将看到以下信息：

  引用:

  Certificate was added to keystore
  [Saving clientssltrusts.jceks]

  创建了文件 clientssltsrts.jceks。
  
• 通过执行下面的命令，使用客户机公钥证书为服务器创建信任存储：

  引用:

  keytool -import -v -noprompt -alias wasclient -file wasclient.cert -keystore serverssltrusts.jceks
          -storepass serverssltrusts -storetype jceks

  完成之后，您将看到以下信息：

  引用:

  Certificate was added to keystore
  [Saving serverssltrusts.jceks]

  创建了文件 serverssltsrts.jceks。
  

现在我们具备了配置示例场景所示的 SSL 连接所需要的所有文件。我们可以使用 wasserver.cert 文件为 .Net 客户机配置 Windows 环境。接下来，我们需要为 Web 服务安全性签名和加密创建密钥和证书。

创建密钥存储
为 Web 服务安全性生成密钥

在我们的实现中有一个客户机和一个服务器：EchoServiceClient 和 EchoService。要允许使用 PKI 技术的数字签名，签署方 (EchoServiceClient) 必须有权使用将其视为签名验证者 (EchoService) 的私钥。签名验证者必须有权使用包含与用于生成签名的私钥关联的公钥的公钥证书。
对于使用 PKI 技术的加密，加密方必须有权使用包含为其加密消息的一方（即解密方）的公钥的公钥证书。而解密方必须有权使用与用于加密消息的公钥关联的私钥。
在我们的场景中，将签署和加密来自和到达服务的请求。实际上，我们的配置将与 SSL 所需的配置几乎完全相同，客户机一方不希望服务的 DN 中的 CN 与服务的 URL 中的主机名相匹配除外。因为 Application Server V5.1 只支持 J2EE 客户机，所以我们不用考虑 J2SE 客户机。
按照约定，我们将密钥存储分为两类，一类包含私钥，一类包含公钥（后者一直包装在公钥证书中）。最后，我们将创建两类密钥存储，一类用于客户机，一类用于服务器。有关下面使用的命令行选项的详细说明，请参阅 keytool 用户指南。

创建密钥存储
为 Web 服务安全性生成密钥

为 EchoService 客户机创建密钥

• 在一行中键入下面的命令创建密钥对和自签署的公钥证书，以表示基于 J2EE 的 EchoService 客户机：

  引用:

  keytool -genkey -v -alias echoserviceclient -keypass echoserviceclient -keystore echoserviceclientkeys.jceks
          -storepass echoserviceclientkeys -storetype jceks -dname \"cn=EchoServiceClient, o=ibm, c=us\" -keyalg \"RSA\"

  完成以后，您将看到以下信息：

  引用:

  Generating 1,024 bit RSA key pair and self-signed certificate (MD5WithRSA)
          for: CN=EchoServiceClient, O=ibm, C=us
  [Saving echoserviceclientkeys.jceks]

  如果您要根据客户机证书中的标识在 Application Server 中建立安全上下文（通过在 Web 服务安全性头中传递客户机证书），您需要使用承载服务的 Application Server 使用的用户注册表中 keytool 命令的 DN。为此，您需要确定希望客户机表示的用户 DN，然后将该 DN 放在 -dname 选项后面的引号中。
  
• 通过键入下面的命令，导出客户机公钥证书以将其导入到受信任的客户机证书的服务器存储中：

  引用:

  keytool -export -v -rfc -alias echoserviceclient -file echoserviceclient.cert -keystore echoserviceclientkeys.jceks
          -storepass echoserviceclientkeys -storetype jceks

  完成以后，您将看到以下信息：

  引用:

  Certificate stored in file