Offload WebSphere web services security tasks to IBM WebSphere DataPower SOA Appliances, Part 1: Configure a web service client and service for asymmetric security

Maximize the flexibility of your web services using the web Services Feature Pack for IBM® WebSphere® Application Server V6.1 and IBM WebSphere DataPower SOA Appliances. The Feature Pack is a standards-based implementation that includes several web services specifications (WS*). WebSphere DataPower SOA Appliances are capable of firewall and security functions at very high speeds. Integrating WebSphere Application Server with WebSphere DataPower SOA Appliances yields a secure and high-performance web service. This article series guides you through the process of integrating WebSphere DataPower SOA Appliances with WebSphere Application Server to improve your secure web service installation.

Share:

Joel Smith (sjoel@us.ibm.com), Senior Software Engineer, IBM

Joel Smith has worked on a variety of operating systems, I/O, and communications subsystems. In recent years he has worked in application middleware in the areas of pervasive computing, application server web services, and web services security.



12 December 2008

Also available in Chinese Russian Spanish

System requirements

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See Implementing WS-Security for Java web services

To follow along with this article, make sure you have:

  • WebSphere Application Server V6.1 with the Web Services Feature Pack
  • IBM Rational Application Developer V7.0.0.6 or later
  • Security credentials for web services security in the form of JCEKS key stores or the private keys or public certificates required for the specified cryptographic operations

In this article

This article covers:

  • Deploying and configuring a secure web service using asymmetric encryption.
  • Using Rational Application Developer to import a sample EAR file and configure web services security policies and binding attachments for a web service Client
  • Using the WebSphere Application Server console to configure the web service Security policies for a sample service
  • Preparing Java™ Cryptography Extension (JCE) and JCEKS security credentials.

Introduction

The Web Services Feature Pack for WebSphere Application Server V6.1 extends web services capabilities to allow messages to be sent asynchronously, reliably, and securely. This extended function supports key web service standards, allowing the flexibility to interoperate with multiple vendors' offerings. The standards supported include:

  • Java API for XML Web Services (JAX-WS)
  • WS-Security
  • WS-Addressing
  • WS-Reliable Messaging
  • WS-Secure Conversation
  • SOAP Message Transmission Optimization Mechanism (MTOM)

This model provides a web services engine that allows flexible configurations for using these diverse standards. Policies and policy sets are provided in various combinations to simplify configuring sophisticated levels of processing for web services.

WebSphere DataPower SOA Appliances are purpose-built network devices that help secure and accelerate XML and web services processing. While WebSphere DataPower SOA Appliances have an extensive list of capabilities and features, this article focuses on their web services aspects. The web services capabilities relevant to this article are XML message-level security processing for encryption and decryption, digital signature signing and verification, WS-Security, XML schema validation, web services management support, and detailed logging and auditing. Secure XML processing can be extremely resource-intensive. WebSphere DataPower SOA Appliances offer XML processing and security that may not be available in traditional XML engines. Allowing WebSphere DataPower SOA Appliances to perform processing-intensive portions of the web service requests speeds up and lightens the load of the application server's web service.

The Web Services Feature Pack for WebSphere Application Server V6.1 includes several web service security policies and policy sets that support a variety of web service security configurations. These policies and policy sets can be selected and configured from the WebSphere Application Server console. New policies can also be created from the console. The flexibility to configure mixed levels of processing to a web service offers a highly tailored level of security and reliability. This modularity further allows portions of the web service to be processed separately. This article demonstrates how to deploy a sample web service and configure the WS-Security default policy set using Rational Application Developer.

Part 2 of this article series will demonstrate how to offload the modular portion of WS-Security processing from the server to WebSphere DataPower SOA Appliances and defer the remaining web service processing to the application server. This allows the appliance to do the resource-intensive processing and the application server to process the application business logic.

The default WS-Security policy secures the message integrity via a digital signature for the body and headers, ensuring message confidentiality via encryption of the body. Applying the default WS-Security policy to a deployed web service configures the web service engine such that the initial request is received by the WS-Security module. The SOAP message is processed to decrypt the message content. Then the digital signature is verified. If the message is successfully processed, it's then sent to the next module in the web services engine. When the response is generated to be sent back to the client, the WS-Security module reverses the security process. A digital signature is generated and placed in the SOAP message. Then the SOAP message is encrypted as specified in the policy, and the request is returned to the client. Figure 1 shows an example of this web service configuration.

Figure 1. Web service configuration with default security policy
Web service configuration with default security policy

In this scenario, all elements of the SOAP message are processed by the web services engine in the Web Services Feature Pack for WebSphere Application Server V6.1. The WS-Security run time is inserted in the web service processing chain when the application is deployed. Configuration parameters defining the desired WS-Security options are specified in the deployment descriptor to determine how the web service processing chain is built. These WS-Security parameters can be specified using either the WebSphere Application Server Console or Rational Application Developer. This article uses the Rational Application Developer method.


Steps for sample configuration

The following configuration steps use Rational Application Developer to import and export a working web service client sample. This scenario may be helpful in understanding the facets of a fully configured web service client application to be used for security processing. You install the web service client on a WebSphere application server from the console. This sample scenario uses the EchoService sample and security credentials shipped on Web Services Feature Pack for WebSphere Application Server V6.1. IBM Rational Application Developer contains WS-Security default policy templates used to configure the example web service client.

WebSphere web service configuration

Perform the following steps:

  1. Make sure the web service samples are installed (there's a description of how to do this in the information center).
  2. To verify incremental progress, install and configure the EchoService client and service.
  3. Run the sample client by launching a browser at http://localhost:9080/wssamplesei/demo.
  4. Using the message type Synchronous Echo should result in the successful response echo strings.

In the next step, you configure WS-Security policies and bindings to verify successful secure communication for the echoed messages. Starting with a working client and service configuration simplifies debugging, if necessary, as more complex configuration steps are completed.


Web services client configuration with Rational Application Developer

These steps describe how to use Rational Application Developer to import the WebSphere Application Server Web Services Feature Pack WSSampleClientSei.ear file, configure the WS-Security default policy and bindings, export the .ear file, and deploy it to WebSphere Application Server.

  1. Start Rational Application Developer.
  2. Enter a new workspace named MyEchoClient.
  3. Select File > Import.
  4. In the J2EE folder, choose EAR file, then choose Next.
    Figure 2. Importing web service client EAR file
    Importing Web service client EAR file
  5. For the EAR file field, browse to and select app_server_root/samples/lib/WebServicesSamples/WSSampleClientSei.ear, then click Next.
  6. In the New Server Runtime panel, at the end of the name field, append WSFP to indicate that you're using the Web Services Feature Pack target run time.
  7. In the Installation directory field, enter the path where the server is installed.
    Figure 3. New server run time
    New server run time
  8. Click Finish. The window shown in Figure 2 will display again.
  9. Click Finish again.
  10. From the Project Explorer pane on the left, select and right-click SampleClientSei, and choose Project Facets.
  11. Click Add/Remove Project Facets.
  12. Select WebSphere 6.1 Feature Pack for Web Services.
  13. Click Finish, then click OK.
    Figure 5. Rational Application Developer Project Facets
    Rational Application Developer Project Facets
  14. Create a policy set attachment for the client application by clicking File > New > Other on the main menu.
  15. In the New wizard, expand Web Services and Policy Set, then click Client Side Policy Set Attachment.
    Figure 6. Create client-side policy set attachments
    Create client-side policy set attachments
  16. Click Next.
  17. Click Add to display the End Point definition Dialog window. Choose the following:
    • Service Name: EchoService
    • Endpoint: EchoServicePort
    • Operation Name: echoOperation
    • Policy Set: WSSecurity default
    • Binding: MyWSSecurityBinding
  18. Click OK.
    Figure 7. Endpoint binding definition
    Endpoint binding definition

Now you need to set up the binding configuration for the digital signature.

  1. For Digital Signature Outbound Message Security Configuration, select WSSecurity, then select Configure.
  2. In the Outbound Message Security Configuration window:
    • Enter STRREF in the Key Information Type field.
    • Enter http://www.w3.org/2001/10/xml-exc-c14n# in the Transform Algorithm field.
    • Click the Key Store Settings button.
  3. In the Key Store Settings Dialog window:
    • Enter ${USER_INSTALL_ROOT}\etc\ws-security\samples\dsig-sender.ks in the Keystore Path field.
    • Enter client in the Keystore Password field.
    • For the Keystore Type, select JKS.
    • In the Key Alias field, enter soaprequester.
    • In the Key Password field, enter client.
  4. Click OK to complete.
    Figure 8. Client digital signature key store settings
    Client digital signature key store settings
  5. To configure the binding configuration for XML encryption, click the XML Encryption Configuration tab at the top of the Binding Configuration Dialog window.
  6. In the Outbound Message Security Configuration, enter KEYID in the Key Information Type field.
  7. Click the Key Store Settings button next to the Outbound Message Security Configuration. In the Key Store Settings Dialog window:
    • Enter ${USER_INSTALL_ROOT}\etc\ws-security\samples\enc-sender.jceks in the Keystore Path field.
    • Enter storepass in the Keystore Password field.
    • Select JCEKS in the Keystore Type drop-down list.
    • Enter Bob in the Key Alias field.
    Figure 9. Client Encryption Key Store Settings
    Client Encryption Key Store Settings
  8. Click OK to finish.
  9. Click the Key Store Settings button next to the Inbound Message Security Configuration. In the Key Store Settings Dialog window:
    • Enter %install%\etc\ws-security\samples\enc-sender.jceks in the Key Store Path field.
    • Enter storepass in the Keystore Password field.
    • For Keystore Type, select JCEKS.
    • Enter Alice in the Key Alias field.
  10. Click OK to finish, then click OK again to close the Binding Configuration Dialog window.
  11. Click Finish to close the Client Side Policy Set Attachment window.
    Figure 10. Web service client binding configuration with Rational Application Developer
    Web service client binding configuration with Rational Application Developer
  12. With the WS-Security policy and bindings complete, now you can publish or export, and install the web service client application on WebSphere Application Server to test.
  13. Prior to testing, configure the EchoService with the WS-Security default policy and binding attachments by expanding Services in the left panel of the WebSphere Application Server console, clicking Service providers, then clicking EchoService in the right panel.
    Figure 11. Configure EchoService WS Security policy
    Configure EchoService WS Security policy
  14. In the right panel, select all the entries.
  15. Click the Attach drop-down menu and select WSSecurity default. Select all the entries.
  16. Click the Assign Binding drop-down menu and select default.
  17. At the top of the screen, click Save. The EchoService is now configured with WS-Security. You can click EchoService in the Name field to confirm the WS-Security and binding settings as depicted in Figure 12.
    Figure 12. EchoService with applied WS-Security policy and bindings
    EchoService with applied WS-Security policy and bindings
  18. Test the client application by pointing your browser to http://localhost:9080/wssamplesei/demo. You can replace localhost in the URL with the host name of the application server where the web service client application is installed. If the web service client application is installed at a different port, be sure to use the port where the web service client application is installed.
  19. The application is now ready to send secure messages to the back-end service. As shown in Figure 13:
    • Select the message type to be sent.
    • Enter the test message string to be sent.
    • Accept the message count default.
    • In the Service URI field, you can choose the IP address, host name, and port of the application server, and port that the message should be sent. The message will be echoed in the window below the Send Message button.
      Figure 13. Binding configuration
      Binding configuration

Conclusion

In this article you used Rational Application Developer to import a sample EchoService client EAR file and enabled it with WS-Security; installed the sample web service client on WebSphere Application Server; installed and configured the EchoService with WS-Security; and used the browser to enter a message to be sent from the web service EchoService client application to the web service EchoService service. The message was echoed back to the web service client.

Prior to the message being sent onto the wire from the client, WS-Security used asymmetric keys to digitally sign and encrypt the message. When the message was received at the application server, WS-Security used the asymmetric keys to verify the digital signature and decrypt the message. The message was then passed to the web service for processing. In this scenario, the message was simply echoed in the response. WS-Security used the asymmetric keys to digitally sign and encrypt the response message prior to sending the message onto the wire. At the client, WS-Security receives the response, validates the digital signature, and decrypts the message. The message is then consequently echoed on the browser screen.

In Part 2 of this series, you'll use the WebSphere DataPower SOA Appliances to perform the WS-Security digital signature and verify, and encryption and decryption portion of the message processing.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services, WebSphere
ArticleID=358541
ArticleTitle=Offload WebSphere web services security tasks to IBM WebSphere DataPower SOA Appliances, Part 1: Configure a web service client and service for asymmetric security
publish-date=12122008