配置用户名令牌

下一部分介绍了配置 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。

[B]配置用户名令牌[/B]

配置客户端
按照以下步骤配置客户端：

• 在 Web 透视图中，单击 EchoServiceClientWeb => Web Content => WEB-INF => wsdl > webservicesclient.xml。
  
• 切换到 Security Extensions 选项卡。
  
• 在 Login Config 部分中，在 Authentication method 字段中，从下拉列表中选择 BasicAuth，然后选中 Nonce 框。
  图 31. 配置客户机登录身份验证
  
  

[B]配置用户名令牌[/B]

配置客户端

• 切换到 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

原文地址 ： http://www-128.ibm.com/developer ... wan/0504_cowan.html
英文版地址： http://www.ibm.com/developerwork ... wan/0504_cowan.html

Configure Web Services Security with WebSphere: Part 2, Digital Signatures and Encryption
只有英文的，地址为： http://www-128.ibm.com/developer ... wan/0505_cowan.html

Part 2, Digital Signatures and Encryption  


Level: Intermediate

Tony Cowan (ttcowan@us.ibm.com), Senior IT Specialist, IBM


13 Apr 2005

In Part 1 of this two-part tutorial, we learned how to use IBM WebSphere Studio Application Developer V5.1.2 (hereafter called Application Developer) to secure a Web service using transport-level security (HTTPS), and how to access it from Java™2 Extended Edition (J2EE), Java 2 Standard Edition (J2SE) and .Net clients. We then added a UsernameToken. In Part 2, we\'ll configure diigital signatures and encryption in a Web services security header and invoke them from a J2EE client.

Overview

Part 2 of this tutorial assumes that you have completed Configure Web Services Security with WebSphere, Part 1: HTTPS, .NET, and UsernameToken, which contains information on the following:

• A description of the sample scenario used in this tutorial.
  
• A description of the set-up required for the tutorial.
  
• Mapping out your key requirements and creating key stores.
  
• Configuring transport-level security.
  
• Configuring SSL for Application Server and non-Application Server based clients.
  
• Configuring a .NET client.
  
• Configuring security to pass a UserNameToken.

Part 1 also contains a link to a downloadable file containing the sample .NET client, scripts, and project file used in this tutorial.

[B]Configure digital signatures [/B]

This section describes the steps required to configure the Web services security (WSS) infrastructure to sign parts of a SOAP message. We\'ll describe the steps required in Application Developer, but these steps are almost identical to the steps required if you use the ATK supplied with the WebSphere Application Server runtime. We\'Il describe how to configure the EchoService client and service to sign and validate a UsernameToken in the Web Services Security header and the message body. Note that the security is being applied only to the traffic from the client to the service. The return traffic is not protected. The process of protecting the return traffic is simply the reverse of the steps shown here. To secure the request traffic, we\'ll work in the Request Sender section of the client deployment descriptor and the Request Receiver section of the service deployment descriptor. To secure the reply traffic, we would work in the Response Sender section of the service deployment descriptor and the Response Receiver section of the client deployment descriptor.