该教程包括两个部分,在第 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 密钥和证书。首先,我们将使用 SSL 保护 HTTP 传输,这里需要证书。其次,客户机将与使用 Web 服务和 Web 服务安全性(包含 XML 签名以及 XML 加密元素)的服务器进行交互,因此这里同样需要证书。
示例场景中的三个客户机都使用 SSL 传输安全性。Servlet 和 Java 2 Standard Edition 客户机使用双向验证的 SSL,而 .Net 客户机只使用服务器身份验证。
只有基于 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. 密钥存储布局示例
当生成使用传输安全性的密钥时,会出现两个问题。第一个问题是,颁发给服务器的证书中专有名称 (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 命令文件。
设置 keytool
- 打开命令提示符,转到目录 c:/WSSLabOne。
- 通过键入下面的命令,将包含 keytool 的目录添加到路径中:
set PATH=<WSAD_Install_Root>/runtimes/base_v51/java/jre/bin/;%PATH%
其中 <WSAD_Install_Root> 是 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>
现在您有了第二个文件,称为 wasclient.cert。
为服务器创建密钥对和证书
- 在一行中键入下面的命令创建密钥对和自签署的公钥证书,以表示 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>
现在您有了一个称为 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 服务安全性签名和加密创建密钥和证书。
在我们的实现中有一个客户机和一个服务器:EchoServiceClient 和 EchoService。要允许使用 PKI 技术的数字签名,签署方 (EchoServiceClient) 必须有权使用将其视为签名验证者 (EchoService) 的私钥。签名验证者必须有权使用包含与用于生成签名的私钥关联的公钥的公钥证书。
对于使用 PKI 技术的加密,加密方必须有权使用包含为其加密消息的一方(即解密方)的公钥的公钥证书。而解密方必须有权使用与用于加密消息的公钥关联的私钥。
在我们的场景中,将签署和加密来自和到达服务的请求。实际上,我们的配置将与 SSL 所需的配置几乎完全相同,客户机一方不希望服务的 DN 中的 CN 与服务的 URL 中的主机名相匹配除外。因为 Application Server V5.1 只支持 J2EE 客户机,所以我们不用考虑 J2SE 客户机。
按照约定,我们将密钥存储分为两类,一类包含私钥,一类包含公钥(后者一直包装在公钥证书中)。最后,我们将创建两类密钥存储,一类用于客户机,一类用于服务器。有关下面使用的命令行选项的详细说明,请参阅 keytool 用户指南。
为 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 <echoserviceclient.cert>
为 EchoService 创建密钥
- 在一行中键入下面的命令创建密钥对和自签署的公钥证书,以表示 EchoService:
keytool -genkey -v -alias echoservice -keypass echoservice -keystore echoservicekeys.jceks -storepass echoservicekeys -storetype jceks -dname "cn=EchoService, o=ibm, c=us" -keyalg "RSA"
您将看到以下信息:
Generating 1,024 bit RSA key pair and self-signed certificate (MD5WithRSA) for: CN=EchoService, O=ibm, C=us [Saving echoservicekeys.jceks]
- 通过键入下面的命令,导出服务器的公钥证书以将其导入到客户机存储中:
keytool -export -v -rfc -alias echoservice -file echoservice.cert -keystore echoservicekeys.jceks -storepass echoservicekeys -storetype jceks
您将看到以下信息:
Certificate stored in file <echoservice.cert>
既然已经为 EchoService 客户机和 EchoSevice 创建了密钥存储,我们需要为客户机和服务器创建信任存储来建立信任域。
创建 EchoClient 密钥存储
现在需要使用客户机中的服务器公钥证书来为客户机创建密钥存储,这样我们就可以使用服务器的公钥验证来自服务器的签名,为服务器加密消息。为此,请键入下面的命令:
|
您将看到以下消息:
|
创建 EchoServer 密钥存储
我们需要使用服务器中的客户机公钥证书来为服务器创建密钥存储,这样我们就可以使用客户机的公钥验证来自客户机的签名,为客户机加密消息。为此,请键入下面的命令:
|
您将看到以下信息:
|
现在已经构建了配置我们的示例场景需要的所有密钥存储文件。下载部分附带的脚本完成了所有这些步骤。第一个版本适用于 Linux™/Unix® 平台,而第二个版本适用于 Windows™。
|
既然已经创建了密钥存储,我们将为服务器和客户机配置安全性。在下面的示例中,我们将使用双向 SSL 向 Web 服务调用提供完整性和机密性。配置双向 SSL 以后我们将 UsernameToken 添加到 Web 服务安全性头中来提供身份验证。您可以看到,实际上,传输级安全性的服务器端配置只需遵循与保护常规 Web 应用程序承载的任何常规 URL 所用的步骤相同的步骤。
- 在服务器列表中双击服务器,打开服务器配置编辑器。
- 切换到 Security 选项卡并执行以下操作:
- 选中 Enable security 复选框。
- 指定
wasuser
作为服务器 ID。 - 指定
wasuser
作为服务器密码。
图 3. 启用安全性
- 保存配置并重新启动服务器。
- 在 Web 透视图中,选择 EchoServiceWeb => Web Deployment Descriptor。
- 单击 Security 选项卡。
- 在 Security Roles 字段中,单击 Add 添加一个新的安全性角色。
- 将该安全性角色命名为 EntityConnectingToEchoServiceUsingSSL。
图 4. 添加安全性角色
- 然后在 Security 页面上,从 Security Roles 选项卡切换到 Security Constraints 选项卡。
- 单击 Add 添加一个新的安全性约束。
- 在 Web Resource Collections 部分中,选择缺省的 Web 资源集合 New Web Resource Collection,并单击 Edit。
- 按照以下步骤编辑集合:
- 将名称设置为 EchoService。
- 选中所有的 HTTP 方法。
- 添加服务 URL /services/EchoService(WSDL 中的 URL 不包含 Web 应用程序上下文根 (context root))。
- 单击 OK。
图 5. 编辑 Web 资源集合
- 在 Authorized Roles 部分中,单击 Edit 添加刚刚创建的角色 EntityConnectingToEchoServiceUsingSSL。
- 在 User Data Constraint 字段中,将数据约束类型改为 Confidential。
- 切换到 Pages 选项卡并检查 Login 部分,确保将 Authentication Method 设置为 Unspecified。
图 6. 注册身份验证方法
如果希望基于传入的客户机证书建立 Application Server 安全上下文,则需要将身份验证方法设置为
Client-Cert
。您必须在证书中使用一个有效的用户 DN 以使证书正常工作。未指定身份验证方法时,默认为 Basic,这意味着 Application Server 将在 HTTP 头中查找用户名和密码。最初我们不会发送该信息,因此必须告诉 Application Server 我们正在保护的 URL 应该允许每一个人访问。在企业应用程序部署描述符中完成该操作,如下所示。
- 保存配置并关闭 Web 应用程序部署描述符编辑器。
- 选择 EchoService => EAR Deployment Descriptor 编辑 EchoService 企业应用程序部署描述符。
- 切换到 Security 选项卡并单击 Gather。
- 选择聚合角色 EntityConnectingToEchoServiceUsingSSL。
- 选中 WebSphere Bindings 下面的 Everyone。这将有效地禁止生成 J2EE 安全上下文,从而使我们不必在客户机证书中使用有效的用户名。
图 7. 指定安全访问
- 保存配置并关闭编辑器。
在为 Application Server 创建 SSL 配置时,可以注意到不能指定密钥别名或密钥密码。从这里可以得出下面的结论:
- 使用 SSL 的用于包含私钥的密钥存储应该只包含一个私钥(它可以包含其他的公钥证书)。
- 密钥密码必须设置为密钥存储密码。
在 Application Developer 中创建 SSL 配置有两种方式:
- 在应用服务器上启用管理控制台,然后使用控制台创建 SSL 配置。
- 在应用服务器配置编辑器中添加 SSL 配置。
- 在服务器透视图中,双击服务器列表中的服务器,打开配置编辑器。
- 切换到 Configuration 选项卡。
- 选中 Server Configuration 下面的 Enable administration console。
图 8. 启用管理控制台
- 保存配置并关闭编辑器。
- 重新启动服务器。
- 在服务器列表中右键单击服务器,选择 Run administrative console。如果出现安全警报,单击 Yes。
- 使用 wasuser 作为用户 ID 和密码,登录到管理控制台。
- 在导航树中,选择 Security => SSL 可以看到 SSL 配置的列表。
- 单击 New 创建一个新的 SSL 配置。
图 9. SSL 配置
- 按照以下操作填写新的 SSL 配置:
- 指定一个与 Application Server 一致的别名;例如:WASServerSSL。
- 将密钥文件名设置为服务器 SSL 密钥文件的文件系统中的完整路径;例如:<path>/serversslkeys.jceks,其中
<path>
为密钥文件的位置。 - 为密钥文件设置密码;例如:serversslkeys。
- 将密钥存储格式设置为适当的存储类型。编辑器将 JCEKS 类型称为 JCEK。
- 将信任文件名设置为服务器 SSL 信任文件的文件系统中的完整路径;例如 <path>/serverssltrusts.jceks,其中 <path>> 为密钥文件的位置。
- 设置信任文件的密码;例如 serverssltrusts。
- 设置信任文件的格式;例如,JCEK。
- 选择 Client authentication。
- 单击 OK 保存配置。请注意,只有单击屏幕顶部的 Save 时才会真正保存配置,但由于我们要对配置进行更多的修改,因此将在完成修改以后保存所有的更改。
图 10. SSL 配置
现在需要设置 Web 容器以在 HTTPS 端口使用新的 SSL 配置。在管理控制台,按照以下步骤进行设置:
- 选择 Servers => Application Servers。
- 在服务器列表中选择 server1。
- 在 Additional Properties 下面,选择 Web Container。
图 10. 选择 Web 容器
- 在 Additional Properties 下面,选择 HTTP Transports。
图 11. 选择 HTTP 传输
可以将 Application Server 配置为在端口 9443 上通过 SSL 公开应用程序。在这里,可以创建新的传输定义并侦听另一个端口,但现在我们只在端口 9443 上修改 SSL 配置。
- 选择与端口 9443 关联的主机名。缺省值为 *,它表示接受任何主机名。
图 12. 选择主机名
- 为该传输更改 SSL 配置以使用新的 SSL 配置 localhost/WASServerSSL。请注意,管理控制台将 localhost/ 作为提供给 SSL 配置的名称的前缀。
图 13. 指定 SSL 配置
- 单击 OK。
- 在屏幕顶部单击 Save 链接,保存配置更改。
- 单击 Save,将这些更改写入配置文件中。
|
基于 Application Server 的客户机是运行于 Application Server 容器内部的 Web 服务客户机。这样的客户机有 Servlet、JSP 和 EJB。完成以下部分中的步骤来配置基于 Application Server 的 Web 服务客户机,以将 SSL 用于客户机到服务的连接。在我们的示例场景中,基于 Application Server 的客户机是在 com.ibm.issw Java 包中的 EchoServiceClientWeb Web 应用程序中实现的 Servlet。我们将使用 Application Developer 对示例场景代码做一些更改。
有两种方法可以更改客户机用于调用服务的端点。第一种方法是修改生成的 Locator 类。然而,这不是一个很好的策略,因为重新生成代理时该类将被重写。更好的方法是,实例化 setEndpoint() 后在代理上调用它。
- 在 Java 透视图中,选择 EchoServiceClientWeb => com.ibm.issw => TestServlet。
- 创建代理对象后在代码中添加一行代码,以在代理对象上调用 setEndpoint(),如下所示。
图 14. 修改代码以调用 setEndpoint()
- 要获取一个有好的开头的 URL 来传递给 setEndpoint(),可以打开所生成的 Locator 类并查找私有最终字符串 echoService_address。
- 选择地址字符串并将其复制到剪贴板。
图 15. 获取 URL 地址
- 切换回 TestServlet 代码并将地址粘贴到对 setEndpoint() 的调用,然后做如下修改:
- 将协议更改为 https。
- 将端口更改为 9443。代码行应该如下所示:
proxy.setEndpoint ("https://localhost:9443/EchoServiceWeb/services/EchoService");
如下图所示:
图 16. 修改 TestServlet 代码
- 保存 TestServlet 代码。
现在我们需要为客户机创建 SSL 配置,以将其用于与服务器进行通信。在为 Application Server 创建 SSL 配置时,可以注意到不能指定密钥别名或密钥密码。从这里可以看出,使用 SSL 的用于包含私钥的密钥存储应该只包含一个私钥(它可以包含其他的公钥证书)。还可以看出,必须将密钥密码设置为密钥存储密码。本练习的步骤与服务器端所用的步骤类似,如下所示:
- 使用 wasuser 作为用户 ID 和密码登录到管理控制台。请注意,您可能已从服务器端的先前配置登录了。
- 在导航树中,选择 Security => SSL 可以看到 SSL 配置的列表。
- 单击 New 创建一个新的 SSL 配置。
- 按照以下操作填写新的 SSL 配置:
- 将别名设置为一个与 Application Server 一致的名称;例如,WASClientSSL。
- 将密钥文件名设置为服务器 SSL 密钥文件的文件系统中的完整路径;例如,<path>/clientsslkeys.jceks,其中 <path> 为密钥文件的位置。
- 为密钥文件设置密码;例如,clientsslkeys。
- 将密钥存储格式设置为适当的存储类型。编辑器将 JCEKS 类型称为 JCEK。
- 将信任文件名设置为服务器 SSL 信任文件的文件系统中的完整路径;例如,<path>/clientssltrusts.jceks,其中 <path> 为密钥文件的位置。
- 设置信任文件的密码;例如,clientssltrusts。
- 设置信任文件的格式;例如:JCEK。
- 单击 OK。
- 单击屏幕顶部的 Save。
- 单击 Save。
图 17. 配置 SSL
既然为客户机创建了 SSL 配置,我们需要告诉 Application Server Web 服务客户机存根调用服务时使用它。为此,我们将指向 SSL 配置的引用添加到 Web 服务客户机部署描述符文件中。
- 在 Web 透视图中,选择 EchoServiceClientWeb => Web Content => WEB-INF => wsdl => webservicesclient.xml。
- 切换到 Port Bindings 选项卡。
- 在 Port Qualified Name Binding Details 部分中,在 HTTP SSL configuration name 字段中输入
localhost/WASClientSSL
。请注意,通过管理控制台添加 SSL 配置时,localhost/
为指定的 SSL 配置的名称的前缀。
图 18. 配置 Web 服务部署描述符
- 重新启动服务器。
- 现在通过使用 URL (
http://localhost:9080/EchoServiceClientWeb/TestServlet
) 调用 TestServlet,可以测试基于 Application Server 的客户机与服务的连接。
|
非基于 Application Server 的客户机是在 Application Server 容器外运行的客户机。这样的客户机有托管 J2EE 客户机应用程序和单机版 J2SE Java 应用程序。
有两种方法可以更改客户机用于调用服务的端点。第一种方法是修改生成的 Locator 类。然而,这不是一个很好的策略,因为重新生成代理时该类将被重写。更好的方法是,实例化 setEndpoint() 后在代理上调用它。为此,按照以下步骤进行操作:
- 在 Java 透视图中,选择 EchoServiceJ2SEClient => com.ibm.issw => TestClient.java。
- 创建代理对象后在代码中添加一行代码,以在代理对象上调用 setEndpoint()。
- 要获取一个有好的开头的 URL 来传递给 setEndpoint(),可以打开所生成的 Locator 类并查找私有最终字符串 echoService_address。
- 选择地址字符串并将其复制到剪贴板。
- 切换回 TestClient 代码并将地址粘贴到对 setEndpoint() 的调用,然后做如下修改:
- 将协议更改为 https。
- 将端口更改为 9443。
- 代码行应该如下所示:
proxy.setEndpoint("https://localhost:9443/EchoServiceWeb/services/EchoService");
如下图所示:
图 19. 配置服务端点
- 保存 TestClient 代码。
对于 Application Developer 附带的 WebSphere 测试环境 (WTE),需要检查是否已配置提供程序。用于检查的文件所在的目录类似于:
|
在 java.security 文件中查找安全性提供程序并添加下面的一行代码:
|
其中 <n> 为下一个未使用的号码。
对于 J2SE 客户机,我们使用 Java 系统属性告诉运行时使用哪些密钥和信任存储。在命令行运行 Java 客户机时,与您定义的任何其他系统属性相同,将系统属性添加到 Java 命令中。我们将在 Application Developer 内部运行 Java 客户机。通过执行以下步骤,在 Application Developer 中将下面的系统属性添加到 JVM 启动命令行中:
- 为了使用一组正确的库而配置 Java 应用程序之前,我们要在 Application Developer 中定义环境变量,以使这一过程变得简单,如下所示:
- 在 Application Developer 中,选择 Window => Preferences。
- 在 Preferences 对话框中,从左边的树中选择 Java => Classpath Variables。
- 选择并编辑变量 WAS_50_PLUGINDIR。我们需要复制该变量的值以使创建新的变量更加简单,因此继续下一步,将该变量的值复制到剪贴板。
- 单击 OK。
图 20. 复制 WAS_50_PLUGINDIR 变量
- 回到 Preferences 对话框,单击 New 创建一个新变量。
- 将新变量称为
WAS_51_PLUGINDIR
并从剪贴板粘贴值。在路径的末尾添加1
,最后,路径如下所示:/opt/IBM/WebSphereStudio/ApplicationDeveloper/v5.1.2/runtimes/base_v51
- 单击 OK。
- 现在让我们配置客户机,以在运行时使用正确的 java jar 文件。为此,按照以下步骤进行操作:
- 右键单击 EchoServiceJ2SEClient 项目,然后从上下文菜单中选择 Properties。
- 在 Properties 对话框中,从左边的菜单中选择 Java Build Path,然后单击 Libraries 选项卡。
图 21. 创建新变量
- 编辑使用变量 WAS_50_PLUGINDIR 的每一个条目,并将其更改为 WAS_51_PLUGINDIR。
图 22. 编辑变量
- 单击 OK 关闭 Properties 对话框。
- 打开 TestClient.java 文件,从 Application Developer 顶部菜单选择 Run => Run...。
- 在 Run 对话框中,切换到 (x)=Arguments 选项卡并在 VM Arguments 部分中输入以下内容:
-Djava.protocol.handler.pkgs=com.ibm.net.ssl.internal.www.protocol -Djavax.net.ssl.trustStore=<path>/clientssltrusts.jceks -Djavax.net.ssl.trustStorePassword=clientssltrusts -Djavax.net.ssl.keyStore=<path>/clientsslkeys.jceks -Djavax.net.ssl.keyStorePassword=clientsslkeys -Djavax.net.ssl.keyStoreType=jceks -Djavax.net.ssl.trustStoreType=jceks
其中 <path> 为密钥文件的位置,例如 <C>/WTE2004/WSSecurity/L10。
图 23. 指定 VM 参数
- 单击 JRE 选项卡并在 JRE 字段中选择 WebSphere V5.1 JRE runtime。
- 单击 Apply,然后单击 Run 来测试 Java 客户机。
图 24. 指定 JRE 运行时
|
配置 .Net 组件以在连接到服务时提供特定的客户端证书是一个复杂的过程。有关详细信息,请参阅 MSDN 库中的 Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication。
我们可以在 Windows 环境中相当容易地配置信任证书,以允许 .Net 客户机信任 Application Server 提供的证书。首先需要更改服务器,使其不需要客户端证书,然后在 Windows 环境中配置客户机使用的服务器证书。
我们将使用 Application Server 管理控制台修改服务器的 SSL 配置。也可以在 Application Developer 中使用服务器配置编辑器做同样的事情。按照以下步骤进行操作:
- 使用 wasuser 作为 ID 和密码登录到管理控制台。请注意,您可能已从前面的配置操作中登录了。
- 从左边的树中,选择 Security => SSL 可以看到 SSL 配置的列表。
- 选择 WASServerSSL 配置,然后单击 Edit。
- 取消选中 Client Authentication 并保存配置。
- 重新启动服务器。
已经创建 Windows 客户机并将其作为基于控制台的 Windows 可执行文件。它将调用服务并在控制台上打印出回显字符串。在 Windows 中,传输机制 HTTP and HTTPS 是由系统组件处理的。这些系统组件在证书管理注册表中查找信息。我们可以使用一个称为 Microsoft 管理控制台 (MMC) 的工具管理 Windows 证书注册表。可以使用 mmc
命令在命令行中调用 MMC。请按照以下步骤配置 Windows 以通过 SSL 进行 Web 服务调用:
- 在 Windows 开始菜单中单击 Run 以启动 MMC,然后在命令名称中键入
mmc
。 - 在主窗口中,选择 Console => Add/Remove Snap-in。
- 在 Add/Remove Snap-in 对话框中,单击 Add。
- 在 Add Standalone Snap-in 对话框中,选择列表中的 Certificates,然后单击 Add。
图 25. 添加证书
- 在 Certificates Snap-in 对话框中,选择 Computer account,然后单击 Next。
- 在 Select Computer 对话框中,确保已选中 Local computer,然后单击 Finish。
- 关闭 Add/Remove Snap-in 对话框。
- 在左边的树中,选择 Certificates (Local Computer) => Trusted Root Certificates。
- 右键单击 Certificates 并选择 All Tasks => Import。
图 26. 导入证书
- 在 Certificate Import 向导中,浏览到包含服务器证书的文件。在我们的示例中,该文件为 wasserver.cert。然后单击 Next。
图 27. 浏览到服务器证书
- 选择 Automatically select the certificate store based on the type of certificate,然后单击 Next。
- 在下一页单击 Next,然后单击 Finish。
- 当出现提示时,回答 Yes。
上面是导入证书的一些步骤。现在可以按照以下步骤运行 .Net 客户机来访问响应服务:
- 打开命令窗口。
- 切换到 <drive>:/WTE2004/WSSecurity/L10 目录。
- 运行 WTE2004Client.exe。
|
下一部分介绍了配置 Web 服务安全性 (WSS) 基础设施来在 WSS 头中传递 UsernameToken 所需的步骤。这一部分描述了 Application Developer 中所需的步骤,不过这些步骤与使用 Application Server 运行时附带的 ATK 所需的步骤几乎完全相同。我们描述了如何配置 Application Server 以在 Servlet 客户机和响应服务之间的 WSS 头中传递 UsernameToken。
按照以下步骤配置服务端:
- 在 Web 透视图中,单击 EchoServiceEJB => ejbModule => META-INF => wsdl => webservices.xml。
- 切换到 Security Extensions 选项卡。
- 打开 Login Config 部分。
- 单击 Add 并从下拉列表中选择 BasicAuth。
图 28. 配置服务器登录身份验证
- 在 Add Authentication Method 对话框中,选择两个 Nonce 框,然后单击 OK。需要 Nonce 以防止重播攻击。
图 29. 添加身份验证方法
- 切换到 Binding Configurations 选项卡,然后在 Login Mapping 部分中单击 Add。
- 在 Login Mapping 对话框中,执行以下操作:
- 在 Authentication method 中指定 BasicAuth。
- 输入配置名称
WSLogin
(区分大小写)。 - 将 Callback handler 设置为
com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl
。 - 其他所有的值都保留缺省值。
- 单击 OK。
图 30. 配置服务器登录映射
- 保存配置,然后选择 EchoService => Restart Project。
按照以下步骤配置客户端:
- 在 Web 透视图中,单击 EchoServiceClientWeb => Web Content => WEB-INF => wsdl > webservicesclient.xml。
- 切换到 Security Extensions 选项卡。
- 在 Login Config 部分中,在 Authentication method 字段中,从下拉列表中选择 BasicAuth,然后选中 Nonce 框。
图 31. 配置客户机登录身份验证
- 切换到 Port Binding 选项卡,并在 Login Binding 部分中单击 Enable。
- 在 Login Binding 对话框中,执行以下操作:
- 对于 Authentication method,选择 BasicAuth。
- 从下拉列表中将 Callback handler 设置为
com.ibm.wsspi.wssecurity.auth.callback.NonPromptCallbackHandler
。 - 输入用户 ID 和密码。
- 单击 OK。
图 32. 配置客户机登录绑定
- 以上是发送静态配置的 UsernameToken 需要做的所有工作。通过使用 URL (
http://localhost:9080/EchoServiceClientWeb/TestServlet
) 调用 TestServlet 测试客户机。
|
描述 | 名字 | 大小 | 下载方法 |
---|---|---|---|
sample .NET client, scripts, project file | wssecurity1.zip | 62 KB | FTP|HTTP |
关于下载方法的信息 | Get Adobe® Reader® |
|
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- developerWorks SOA and Web services 专区提供有关 SOA 和 Web 服务方面的文章、下载和其他资源。
- developerWorks WebSphere Web services 专区提供有关 WebSphere 和 Web 服务方面的文章和其他资源。