WS-Notification in WebSphere Application Server V7: Part 2: Configuring JAX-WS applications with WS-Security for WS-Notification

Learn how to configure the Java™ API for XML-based Web Services (JAX-WS) applications for use with the updated WS-Notification functionality running on secured IBM® WebSphere® Application Server V7.0. This article describes how to secure WS-Notification JAX-WS applications by using WS-Security, including how to enable WebSphere Application Server security, how to create a Version 7.0 WS-Notification service, and how to associate a WS-Security policy set and binding with the WS-Notification applications. This content is part of the IBM WebSphere Developer Technical Journal.

Emily Jiang (emijiang@uk.ibm.com), Software Engineer, IBM

Author1 photoEmily is a software engineer at IBM Hursley Park in United Kingdom. She tests Web Service functionality in WebSphere Application Server V7.0, with a particular focus on WS-Notification, WS-Policy, WS-MetadataExchange and WS-Security.



08 April 2009

Also available in Chinese

Introduction

WS-Notification provides an open standard for Web services communication using a topic-based publish/subscribe messaging pattern. As mentioned in WS-Notification in WebSphere Application Server V7: Part 1, IBM WebSphere Application Server V7.0 implements WS-Notification based on the Java API for XML-based Web Services (JAX-WS), known as Version 7.0 WS-Notification. If you create a Version 7.0 WS-Notification Service, you can configure it with policy sets such as WS-ReliableMessaging or WS-Security. This article focuses on how to compose a WS-Notification service with a WS-Security policy set in a secured Version 7.0 WebSphere Application Server.

A WebSphere Application Server “policy set” is a collection of assertions about how a Web services is defined. You use policy sets to simplify configuration and combine both transport and message level configuration settings, relating to areas such as WS-Addressing, WS-ReliableMessaging, WS-Security, HTTP Transport, JMS Transport and SSL Transport. Policy sets only apply to JAX-WS applications and not to Java API for XML-based RPC (JAX-RPC) applications.

WS-Security provides end-to-end message security, which ensures the messages will not be manipulated during transmission, as well as providing confidentiality. WebSphere Application Server V7.0 provides a number of default WS-Security policy sets. For this article, we chose the Username WSSecurity default policy set to secure WS-Notification applications. This policy set contains basic authentication capability together with message-level security.

In a production environment, it is recommended to have WebSphere Application Server security enabled to prevent unauthorized users from accessing your system. When you install WebSphere Application Server V7.0, administrative security is enabled by default unless you choose otherwise.

The following procedure describes at a high level how to set up a secure WebSphere Application Server and then configure the WS-Notification service and other applications with a WS-Security policy set. The procedure is applicable for both single server and cluster topologies. The topology used in this article is a standalone application server.

The procedure is as follows:

  1. Configure WebSphere Application Server V7.0 with administrative security
  2. Create a Version 7.0 WS-Notification service and a service point in WebSphere Application Server V7.0
  3. Deploy the JAX-WS applications:
    • WS-Notification producer and subscriber
    • JAX-WS based WS-Notification consumer Web service.
  4. [Optional step] Use HTTPS transport between the client and tbe service provider, by specifying SOAP over HTTPS as the binding for your WS-Notification service point.
  5. Apply the policy set Username WSSecurity default and an appropriate binding to the WS-Notification service point and service client, and also to your JAX-WS producer, subscriber and consumer applications.

The remainder of this article details the above steps. The first part of this article describes how to set up the system and install the required applications. The second part details how to configure the WS-Notification applications with the chosen policy set and binding. Finally, a walkthrough example is included.


Prerequisite

This article assumes that you are creating a single WebSphere Application Server and using a single notification broker to enable individual producer and consumer WS-Notification applications to communicate with each other.

To create your own WS-Notification application consisting of a JAX-WS Web service client and associated artifacts, follow the instructions in part 1 of this series of articles or see the IBM information center topic Using JAX-WS clients and Web services with new Version 7.0 WS-Notification service points.


Configure WebSphere Application Server security

There are two ways to enable administrative security: during profile creation, or after profile creation.

Create an application server profile with security enabled

You can create an application server profile during WebSphere Application Server installation and request that administrative security be enabled for that profile. During profile creation, the Enable Administrative Security screen, shown in Figure 1, is displayed with the Enable administrative security option selected by default. If you keep this as the default, you must supply an administrative user name (we use SecureWsn in this article) and password (we use SecureW5n in this article). This user name is created in a federated repository, which is the default user registry when enabling administrative security at profile creation time. WebSphere Application Server supports the following types of user registries:

  • Federated repository
  • Local operating system registry
  • Standalone Lightweight Directory Access Protocol (LDAP) registry
  • Standalone custom registry

This article chooses the Federated repository as the user registry. The rest of this article is not affected by the user registry you choose. Refer to the IBM InfoCenter, Selecting a registry or repository for more details about other registries.

Figure 1: Administrative Security window during installation
Screen shot of Administrative Security window

After installation, you can also create an application server profile. During profile creation, you can enable administrative security and specify your user name (e.g. SecureWsn) and password (e.g. SecureW5n), as shown in Figure 2.

Figure 2: Administrative Security during profile creation
Screen shot of Administrative Security during profile creation

Enable security after profile creation

If you have created a profile with security disabled, follow these steps to enable administrative security.

  1. Navigate to the Global security window by selecting Security=>Global security. The window in Figure 3 will be displayed.
    Figure 3: Global security
    Screen shot of Global security window
  2. Select Security Configuration Wizard and then configure security using Federated repositories.

    • Step 1- Specify the extent of protection (shown in Figure 4).
      The scenario detailed in this article has no ‘application security’. On the following window, deselect Enable application security and then click Next.
      Figure 4: Configure security - Step 1
      Screen shot of Step 1
    • Step 2 - Select user repository (Figure 5).
      Choose Federated repositories, and click Next.
      Figure 5: Configure security - Step 2
      Screen shot of Step 2
    • Step 3 - Configure federated repository (Figure 6).
      Enter your user name (e.g. SecureWsn) and password (e.g. SecureW5n). The user name and password will be used when you log in to the administrative console. Click Next.
      Figure 6: Configure Security - Step 3
      Screen shot of Step 3
    • Step 4 – Summary.
      Click Finish and then save the changes. Restart the application server. You will notice that when you log in to the administrative console, a user name and password are now required. Enter your user name (e.g. SecureWsn) and password (e.g. SecureW5n) to log in to the WebSphere Application Server.

Create a WSN service and necessary resources

To interact with the new JAX-WS-based WS-Notification Web services, you need to configure the application server to expose one or more WS-Notification service points. To achieve this, download the sample script included in this article, WAS7_WSN_JAXWS_Part2_Setup.py. Execute these configuration steps or use the administrative console to achieve the same result, as described below.

Create a Service Integration Bus and add the server as a bus member

This section is about creating a bus and then adding the server to the bus as a bus member. If you have a bus with bus security enabled and a bus member configured, you can skip this section.

Create a Service Integration Bus

A Service Integration Bus is a mandatory resource in WS-Notification. As mentioned earlier, WS-Notification supports the publish/subscribe message pattern. The notifications published by WS-Notification applications are inserted into the service integration bus where they can be modified, rerouted or consumed by any of the other applications that are connected to the bus. Equally, publications sent by service integration bus clients such as JMS can be received by WS-Notification consumers. Next we will create a bus:

  1. Navigate to the Buses administrative panel in your WebSphere Application Server instance by selecting Service integration=>Buses.

  2. Click the New button to create a new bus, which displays the window in Figure 7. Enter the bus name for your new bus and keep Bus security selected, as shown in Figure 7. The bus name is WSNBus in this article.
    Figure 7: Create a new Service Integration Bus
    Screen shot of creating a new Service Integration Bus
  3. Accept all default settings in the next steps and then click Finish on Step 2.

The newly created bus, WSNBus, has security enabled. Securing a service integration bus provides the bus with an authorization policy to prevent unauthorized users from gaining access. In other words, only an authorized user can access the bus to put or retrieve messages. Therefore, for a WSN service to access the bus, the necessary credentials such as user name and password must be provided.

Add the server as a bus member

You need to add the application server as a bus member, so that you can create a message engine and used it to manage messaging resources. You can configure the message engine to use a file store or a data store. We use a file store in this article.

  1. To add the server as a bus member, select Service integration=>Buses => your_bus_name=>[Topology] bus members, where your_bus_name is the bus name you have just created (e.g. WSNBus). Click the Add button to display the window in Figure 8:
    Figure 8: Add a new bus member
    Screen shot of adding a new bus member
  2. Accept all default settings in the following steps and then click ‘Finish’.

Create a Version 7.0 WS-Notification service and service point

You can skip the section if you have already created a Version 7.0 WS-Notification service and service point using a dynamic topic namespace. However, we recommend that you create a separate WS-Notification service by following these instruction:

  1. Navigate to WS-Notification services in the administrative panel of your WebSphere Application Server instance by selecting Service integration =>WS-Notification=>Services.

  2. Create a new WS-Notification service by clicking New. The following steps show you how to create a WS-Notification service.

    • Step 1 Configure WS-Notification name (Figure 9).
      Enter the WS-Notification service name. In this article, the WS-Notification service is called WSNSecureService. Make sure your newly created bus is selected as your Service integration bus, called WSNBus. Click Next.
      Figure 9: New WS-Notification service - Step 1
      Screen shot of the new service
    • Step 2: Select WS-Notification service type.
      You can create a version 6.1 or version 7.0 WS-Notification. Select Version 7.0 as the type of service that you want to create. Click ‘Next’.

    • Step 3: Optionally, configure hander and Web service policy settings.
      Choose a JAX-WS handler list to apply to outbound requests made by the Version 7.0 WSN service. Accept the default setting, and click Next.

    • Step 4: Create a WS-Notification service point (Figure 10).
      The Service point defines an access point to the WS-Notification service on a given bus member through a specified Web service binding (SOAP over HTTP). Click Next.

      • Step 4.1: Configure service point name.
        Enter the name for the service point (e.g. WSNSecureServicePt) as shown in Figure 10. Ensure the bus member you just created is selected under select a bus member. and click Next.
        Figure 10: New WS-Notification service point - Step 4.1
        Screen shot of the new service point
      • Step 4.2: Define transport settings.
        Accept the default setting (SOAP over HTTP) in Step 4.2, and click Next. At the end of the Step 4, choose No for Create another service point, as shown in Figure 11. Click Next.
        Figure 11: New WS-Notification service - Step 4
        Screen shot of Step 4 for the new service
    • Step 5: Create permanent topic namespaces.
      Accept the default and choose No for Create a new instance, shown in Figure 12, which means that the WS-Notification service will use a dynamic topic space. A permanent topic space is required if your WS-Notification service will interact with JMS applications or you want to apply restrictions to your topic structure. In this article we use a dynamic topic space instead. Refer to the WebSphere Application Server v7.0 InfoCenter for more information about the difference between a dynamic topic space and a permanent topic space. Click Next.
      Figure 12: New WS-Notification service - Step 5
      Screen shot of Step 5 for the new service
    • Step 6: Summary.
      Click Finish on the summary page, which creates a WS-Notification service and service point.

  3. Restart the Application Server.
    Restart the application server to start the WS-Notification service point. Navigate to the Enterprise Application page by selecting Applications=>Application Types => WebSphere enterprise applications, and you will find a new WS-Notification service application is listed, e.g. WSN_WSNSecureService_WSNSecureServicePt. After the WS-Notification service is created, this application exposes the WS-Notification Web service interfaces for each of the three WS-Notification service roles:

    • Notification broker
    • Subscription manager
    • Publisher registration manager

Deploy WSN publisher, subscriber and consumer

As mentioned in part 1 of this WS-Notification series, to use the WS-Notification service, three applications are normally deployed: a WSN publisher, a WSN subscriber and a WSN consumer. (Note that in some cases the application designer may choose to combine the subscriber and consumer roles into a single application.) In this article, we used the following three applications:.

  • WSNPublisher.ear – publishes WS-Notification messages
  • WSNConsumer.ear – consumes WS-Notification messages published by WSN publishers
  • WSNSubscriber.ear – make subscriptions on a particular topic, at a WS-Notification Service via a WS-Notification service point

You can Download each of the above applications in this article. Deploy the three applications by using the administrative console to navigate to Applications =>New Application=>New Enterprise Application. Figure 13 shows the console after you have created a WS-Notification service and installed the above WS-Notification applications.

Figure 13: Installed WS-Notification applications
Screen show of the installed applications

Secure the transport [Optional]

This step is optional. It demonstrates that you can use transport-level security together with message-level security. Transport-level security encrypts the complete communication (on a single network hop) between client and service, while message-level security only encrypts the SOAP message. Transport-level security provides point-to-point security, which falls short for Web services because we need end-to-end security, where multiple intermediary nodes could exist between the two endpoints. Message-level security provides end-to-end message protection. When securing WS-Notification applications, you can just use message-level WS-Security by excluding this section. This article demonstrates that you use both transport and message-level security to secure your WS-Notification applications.

By default the SOAP over HTTP endpoints used by service points accept both HTTP and HTTPS requests. HTTP itself is an insecure protocol because all information is sent in clear text. To secure HTTP, you can apply transport-level security, which secures Web services messages over the underlying transport.

HTTPS is selected by changing the endpoint URL prefix to https:// on each WS-Notification service point for your WS-Notification service, and modifying the port to refer to the HTTPS port used by the server (default of 9443). To achieve this, follow these instructions:

  1. Navigate to Provide HTTP endpoint URL information by selecting Applications=>Application Types=>WebSphere enterprise applications =>application name =>[Web Services Properties] Provide HTTP endpoint URL information. The application name is your Web Service provider, such as WSNConsumer, WSN_WSNSecureService_WSNSecureServicePt

  2. Select all modules in the application by clicking all check boxes.

  3. Specify the endpoint URL prefix for the HTTPS protocol, demonstrated in Figure 14 (where the machine host name is hidden on purpose). Select the default HTTPS prefix (https://your_host_name:9443) from the predefined list of Select default HTTP URL prefix, where your_host_name is the hostname of your WebSphere Application Server installation machine. Click Apply to apply the HTTPS URL prefix to the selected modules.
    Figure 14: Provide HTTP endpoint URL information
    Screen shot of HTTP endpoint URL information

Repeat the above operations for both the WS-Notification service point application, WSN_WSNSecureService_WSNSecureServicePt, and your WSNConsumer application to configure your service providers to use the secure transport HTTPS.

After you have saved your changes, publish the WS-Notification service point’s WSDL files (NotificationBroker.wsdl, PublisherRegistrationManager.wsdl and SubscriptionManager.wsdl) by navigating to Enterprise Applications=>WSN_WSNSecureService_WSNSecureServicePt=>[Web Services properties] Publish WSDL files. You will notice that the endpoint URLs for the three Web service ports start with https://your_host_name:9443. Please note that the configuration just exposes the endpoint as HTTPS and you still can access the non-secure port. If you want to enforce the client to use HTTPS only, you need to attach HTTPS policy type on the WS-Notification service point and WSNConsumer, which is out of scope of this article.


Configure the WS-Notification applications with a WS-Security policy set and binding

After creating the WS-Notification service, you can attach the appropriate policy set and binding to the WS-Notification applications. The policy set used in this article is Username WSSecurity default, which carries basic authentication plus message-level security. Policy-set binding contains platform-specific information, like keystore, authentication or persistence information. Whenever you attach a WS-Security policy set to an application, you need to attach the corresponding binding file. The following steps detail how to create the binding file for the policy set Username WSSecurity default, and then how to attach the policy set and binding to the WS-Notification applications.

Attach a Policy set and binding to the JAX-WS applications

For JAX-WS applications, you can attach a WS-Security policy set and binding to secure the messages.

As mentioned above, you associate a binding with a policy set, as the binding contains information about the keystore, the key to use for digital signatures and encryption, and authentication and persistence information. In WebSphere Application Server V7.0, there are two types of bindings: application bindings and general bindings. A general binding is new to WebSphere Application Server V7.0. An application binding is private to a particular application while multiple applications can reuse a general binding. This article uses general bindings to reuse the binding for different applications.

There are two types of general bindings:

  • General provider policy set bindings - applicable to Web service providers
  • General client policy set bindings - applicable to Web service clients

Create a general client/provider binding for a policy set

One easy approach to create a general binding is to copy an existing client/provider binding and then edit the newly created binding. This article uses the default general bindings, Sample client and Sample provider, as templates for demonstration only. Please note that as the sample bindings use sample keys and keystores, you are advised not to use the sample general bindings for production, and must change the keys and keystores.

To create the general client binding:

  1. Copy the Client sample binding.

    Navigate to the General client policy set bindings page by selecting Services=>Policy sets => General client policy set bindings. You can create a new binding by clicking New…. Choose the Client sample binding and then click copy…. In the copy of Client sample window, enter a name for the newly created binding, called WSNClientGeneralBinding in this article. Click OK and then save the change.

  2. Edit the newly created binding.
    The newly created client binding, e.g. WSNClientGeneralBinding, needs to contain user name and password details so that the associated application can use this information to access the bus and topic space.

    Navigate to ‘Callback Handler’ panel by accessing Services => Policy Sets => General client policy set binding => client_binding_name => WS-Security =>Authentication and protection => gen-signunametoken => [Additional bindings] Callback handler. The client_binding_name is the binding you just created, WSNClientGeneralBinding. Enter your administrative user name (e.g. SecureWsn) and password (e.g. SecureW5n), as demonstrated in Figure 15. Click OK and then save your change.
    Figure 15: General client policy set and bindings - Callback handler
    Screen shot showing basic authentication

To create a general provider binding:

  • Copy the Provider sample binding.
    Similar to copying the Client sample binding, copy the Provider sample binding by selecting Services => Policy sets => General provider policy set bindings. In this article, we called the newly created provider binding WSNProviderGeneralBinding.

To configure the newly created binding:

In WSNProviderGeneralBinding, you need to specify the authentication method by configuring the caller settings, which specify the token or message part used for authentication.

  1. Select Services => Policy Sets => General provider policy set bindings => provider_binding_name => WS-Security => Caller. The provider_binding_name is the binding you just created, WSNProviderGeneralBinding.

  2. Click New to create a caller.

  3. Enter a caller name in the Name field, detailed in Figure 16. This article uses wsnCaller as the caller name. In the Caller identity local part field, enter the user name token:

    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken

    The Caller means that this token is selected to create the WebSphere Security Context.

  4. Click OK and then save the changes.
    Figure 16: General provider policy set and bindings - Caller
    Screen shot of Caller name

Attach a policy set and binding via the administrative console

As mentioned earlier, when you attach a policy set to your application, you also need to attach an appropriate binding to specify the configuration. The following sections detail how to attach the policy set Username WSSecurity default and the general client/provider binding.

To attach the Username WSSecurity default policy set and WSNClientGeneralBinding binding to the JAX-WS service clients:

  1. To attach the policy set and binding to WSNPublisher, select Applications =>Application Types => WebSphere enterprise applications => WSNPublisher => [Web Service properties] Service client policy sets and bindings.

  2. Attach the Username WSSecurity default policy set on the application scope by clicking the top check box and then selecting Attach Client Policy Set. In the dropdown list of the policy sets, choose Username WSSecurity default, as shown in Figure 17.
    Figure 17: Service client policy sets and bindings – 1
    Screen shot showing how to attach client policy set
  3. Next we’ll attach the WSNClientGeneralBinding binding. Choose the resource by clicking on the top checkbox, and select Assign Binding. Choose your client binding from the binding list, such as WSNClientGeneralBinding.

  4. Save your configuration. Figure 18 shows the policy set and binding configuration.
    Figure 18: Service client policy sets and bindings - 2
    Screen shot showing the policy set and binding configuration
  5. Perform the same operations for WSNConsumer and WSNSubscriber.

To attach the policy set ‘Username WSSecurity default’ and provider binding to the JAX-WS service providers:

In this article, there are two JAX-WS service providers: WSNConsumer, and WSN_WSNSecureService_WSNSecureServicePt.

  1. Select Applications => Application Types => WebSphere enterprise applications => application_name => Service provider policy sets and bindings, where the application_name is the WSNConsumer or WSN service point application, e.g. WSN_WSNSecureService_WSNSecureServicePt.

  2. Use the instructions from the previous section to attach the Username WSSecurity default policy set and WSNProviderGeneralBinding provider binding to the two applications. Figure 19 shows the policy set and binding attachment.
    Figure 19: Service provider policy sets and bindings
    Screen shot showing the policy set and binding attachment

To attach the policy set Username WSSecurity default and client binding to the WS-Notification service client:

  1. Navigate to the WS-Notification outbound request policy set and binding screen by selecting Service integration => WS-Notification => Service => WSN_client_name => [Additional Properties] Outbound request policy set and binding, where WSN_client_name is WSNSecureService in this article.

  2. Attach the Username WSSecurity default policy set and client binding, e.g. ‘WSNClientGeneralBinding’, to the WSNSecureService WSN client.

For the WS-Notification service client, the policy set attachments are not supported at the endpoint (port) or operation level. Therefore endpoints or operations are not selectable, and are shown as inheriting any policy set or binding that is attached to the service client.

You can also attach the policy set and binding to the WS-Notification outbound request through the Service clients page, by selecting Service => Service clients.Then select the OutboundNotificationService and OutboundRemotePublisherService services to attach the Username WSSecurity default policy set and the WSNClientGeneralBinding client binding.


Example scenario: subscribe, publish and consume

The final part of this article describes an example scenario where we use our sample publisher, consumer, and subscriber to publish and consume encrypted notification messages in a secure WebSphere Application Server v7.0.

Prepare your system

If you have not configured your system as described in the previous sections of this article, you can use the instructions and scripts below to prepare your system automatically. If you have followed the instructions in the previous sections and configured your system, you only need to perform steps 8 and 9:

  1. Install WebSphere Application Server V7 with a single server profile with global security enabled (by accepting all default settings). Specify SecureWsn as your user name and SecureW5n as your password. Restart your application server.

  2. Unzip the Download and run the example Version 7.0 WS-Notification configuration script by issuing this command to create a version 7.0 WS-Notification service:

    <WAS>\bin\wsadmin -f WAS7_WSN_JAXWS_Part2_Setup.py WSNBus 
    WSNSecureService WSNSecureServicePt

    Since your administrative security is enabled, when you execute a wsadmin command, you will be prompted for a user identity and password. Enter your administrative user id (SecureWsn) and password (SecureW5n) in the window shown in Figure 20.
    Figure 20: wsadmin command execution login window
    Screen shot of wsadmin login

    Alternatively, you can execute the wsadmin command by supplying your user name and password in the command line, detailed below. However, we do not recommend you use this approach in a production environment, because it would reveal your user name and password:

    <WAS>\bin\wsadmin -f WAS7_WSN_JAXWS_Part2_Setup.py WSNBus 
    WSNSecureService WSNSecureServicePt -username SecureWsn -password SecureW5n

    Use the same approach for the following wsadmin command executions.

  3. Install the three EAR files, also found in the download file, into your application server by executing the command below. These files contain the sample publisher, consumer, and subscriber components, along with HTTP servlets that enable you to compose and invoke WS-Notification requests.

    <WAS>\bin\wsadmin -f WAS7_WSN_JAXWS_Part2_Install_Apps.py 
    WSNPublisher.ear WSNSubscriber.ear WSNConsumer.ear
  4. Next we attach the WS-Security policy set (Username WSSecurity default) and binding to the JAX-WS applications. First, you create general bindings:

    <WAS>\bin\wsadmin -f WAS7_WSN_JAXWS_Part2_Create_Bindings.py 
    WSNClientGeneralBinding WSNProviderGeneralBinding

    The WSNClientGeneralBinding contains the user name (SecureWsn) and password (SecureW5n). If you have chosen a different user name and password, refer to the section Create a general client/provider binding for a policy set to update the user name and password in the binding to match your user name and password set in Step 1.

  5. Attach the policy set and binding to JAX-WS WS-Notification applications.

    <WAS>\bin\wsadmin -f WAS7_WSN_JAXWS_Part2_AttachPolicySetBinding.py 
    WSNPublisher usernamewssecuritydefault WSNClientGeneralBinding WebService:/ client 
    WSNSubscriber usernamewssecuritydefault WSNClientGeneralBinding WebService:/ client 
    WSNConsumer usernamewssecuritydefault WSNClientGeneralBinding WebService:/ client 
    WSNConsumer usernamewssecuritydefault 
    WSNProviderGeneralBinding WebService:/ application 
    WSN_WSNSecureService_WSNSecureServicePt usernamewssecuritydefault 
    WSNProviderGeneralBinding WebService:/ application
  6. Attach the policy set and binding to the WS-Notification client.

    <WAS>\bin\wsadmin -f WAS7_WSN_JAXWS_Part2_AttachPolicySetBindingWSNOutbound.py 
    WSNBus WSNSecureService usernamewssecuritydefault 
    WSNClientGeneralBinding WebService:/
  7. [Optional step] Configure use of the secure transport protocol by following the instructions detailed in Secure the transport [Optional]

  8. Restart the application server.

  9. Open a Web browser and create three browser tabs (or open three Web browsers), and load the following URLs (the HTTPS URLs for WSN Subscriber, Publisher and Consumer):

    https://localhost:9443/WSNSubscriberWeb/SubscriberServlet
    https://localhost:9443/WSNPublisherWeb/PublisherServlet
    https://localhost:9443/WSNConsumerWeb/ConsumerServlet

    If you want to use the insecure transport protocol, the HTTP URLs for WSN Subscriber, Publisher and Consumer are:

    http://localhost:9080/WSNSubscriberWeb/SubscriberServlet
    http://localhost:9080/WSNPublisherWeb/PublisherServlet
    http://localhost:9080/WSNConsumerWeb/ConsumerServlet

The Web pages show input fields and buttons for invoking WS-Notification functionality, as well as the results of any requests and messages that are published and consumed.

Make subscriptions

In the Web browser for the WSN subscriber, enter the values for the Broker port address, Broker service nameand Consumer URI, then click Subscribe, as shown in Figure 21.

The Broker port address and Consumer URI use HTTPS protocol in this article.

The WS-Notification broker’s WSDL contains the Broker port address and Broker service name. You can view the WSDL via Publish WSDL files on the administrative console or by using the ?wsdl query, for example: https://localhost:9443/WSNSecureServiceWSNSecureServicePtNB/Service?wsdl.

Figure 21: WS-Notification subscriber
Screen shot of Subscriber

To verify whether the SOAP message is encrypted, which is the effect of message-level security (independent on whether you use transport-level security), you may turn on the Web service messaging trace (com.ibm.ws.websvcs.trace.MessageTrace=all) to view the SOAP message.

In the trace.log, you can find the SOAP message by searching for the string “:Envelop”. Listing 1 shows the subscription request SOAP message. Because the message body is too big, this article only lists the partial SOAP message with “…” representing the deleted encrypted characters, shown in bold. Because of the WS-Security policy set, the message is encrypted to display some random characters instead of the meaningful messages, such as topic name etc.

Listing 1
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
 <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <wsse:Security xmlns:wsse=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
           soapenv:mustUnderstand="1">
  <wsu:Timestamp xmlns:wsu=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
           wsu:Id="wssecurity_signature_id_21">
    <wsu:Created>2009-03-10T21:47:20.241Z
    </wsu:Created>
   </wsu:Timestamp>
   <wsse:BinarySecurityToken xmlns:wsu=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
     wsu:Id="x509bst_26" EncodingType=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0
     #Base64Binary" ValueType=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
     MIICQzCCAaygAw…
   </wsse:BinarySecurityToken>
   <enc:EncryptedKey xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
    <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5">
    </enc:EncryptionMethod>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <wsse:SecurityTokenReference>
      <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/
        oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType=
        "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0
            #X509SubjectKeyIdentifier">QdZLf+KjrUg …
    </enc:CipherValue>
    </enc:CipherData>
     <enc:ReferenceList>
      <enc:DataReference URI="#wssecurity_encryption_id_27">
      </enc:DataReference>
      <enc:DataReference URI="#wssecurity_encryption_id_28">
      </enc:DataReference>
      <enc:DataReference URI="#wssecurity_encryption_id_29">
      </enc:DataReference>
     </enc:ReferenceList>
   </enc:EncryptedKey>
   <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#" 
        Id="wssecurity_encryption_id_27" Type="http://www.w3.org/2001/04/xmlenc#Element">
     <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">
     </enc:EncryptionMethod>
    <enc:CipherData>
      <enc:CipherValue>3aC/…</enc:CipherValue>
    </enc:CipherData>
   </enc:EncryptedData>
   <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#" 
       Id="wssecurity_encryption_id_29" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">
    </enc:EncryptionMethod>
    <enc:CipherData>
     <enc:CipherValue>p4Pz6…</enc:CipherValue>
    </enc:CipherData>
   </enc:EncryptedData>
  </wsse:Security>
  <wsa:To xmlns:wsu=
  "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
   wsu:Id="wssecurity_signature_id_23">
   https://localhost:9443/WSNSecureServiceWSNSecureServicePtNB/Service</wsa:To>
  <wsa:MessageID xmlns:wsu=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
   wsu:Id="wssecurity_signature_id_24">
   urn:uuid:B3349624E620E4ED2D1236721647734</wsa:MessageID>
  <wsa:Action xmlns:wsu=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
       wsu:Id="wssecurity_signature_id_25">
   http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest</wsa:Action>
 </soapenv:Header>
 <soapenv:Body xmlns:wsu=
   "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
   wsu:Id="wssecurity_signature_id_22">
  <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#" 
    Id="wssecurity_encryption_id_28" Type="http://www.w3.org/2001/04/xmlenc#Content">
   <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">
   </enc:EncryptionMethod>
   <enc:CipherData>
     <enc:CipherValue>JznKewK…</enc:CipherValue>
   </enc:CipherData>
  </enc:EncryptedData>
 </soapenv:Body>
</soapenv:Envelope>

For your comparison, below is the subscription message without using message-level security. The topic name, consumer URL, etc, showing in bold, are displayed in the SOAP message.

Listing 2
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
 <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <wsa:To>
    https://localhost:9443/WSNSecureServiceWSNSecureServicePtNB/Service
  </wsa:To>
  <wsa:MessageID>
    urn:uuid:81DC46116B457C9CD91236876531161
  </wsa:MessageID>
  <wsa:Action>
http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/SubscribeRequest
  </wsa:Action>
 </soapenv:Header>
 <soapenv:Body>
   <ns3:Subscribe 
    xmlns="http://docs.oasis-open.org/wsrf/bf-2"
    xmlns:ns2="http://www.w3.org/2005/08/addressing"
    xmlns:ns3="http://docs.oasis-open.org/wsn/b-2"
    xmlns:ns4="http://docs.oasis-open.org/wsrf/rp-2"
    xmlns:ns5="http://docs.oasis-open.org/wsn/t-1"
    xmlns:ns6="http://docs.oasis-open.org/wsn/br-2"
    xmlns:ns7="http://docs.oasis-open.org/wsrf/r-2">
   <ns3:ConsumerReference>
    <ns2:Address>
     "https://localhost:9443/WSNConsumerWeb/PushNotificationConsumer"
    </ns2:Address>
   </ns3:ConsumerReference>
   <ns3:Filter>
    <ns3:TopicExpression 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:type="ns3:TopicExpressionType"
      Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"
      xmlns:test="http://wsn.jaxws.dw/topicns01">
      test:dW
    </ns3:TopicExpression>
   </ns3:Filter>
   <ns3:InitialTerminationTime>
    P1Y
   </ns3:InitialTerminationTime>
  </ns3:Subscribe>
 </soapenv:Body>
</soapenv:Envelope>

Publish messages

In the browser tab of WSNPublisher, enter the values for the Broker port address and Broker service name used when making a subscription, shown in Figure 22. Enter the message body you want to publish in the Message payload field and then click Publish. This step publishes the message payload. Examine the trace.log for the SOAP message published by the WSNPublisher, which should be encrypted.

Figure 22: WS-Notification publisher
Screen shot of Publisher

Consume messages

Navigate to the WSN consumer tab to verify whether the consumer received the message you just published. You will need to refresh the browser to ensure that the latest consumer status is displayed, as Figure 23 shows:

Figure 23: WS-Notification consumer
Screen shot of Consumer


Examine the trace.log file for the SOAP message received by the consumer, which should be encrypted. The consumer then decrypted the message. The WSNConsumer in this article is implemented to simply display the message content in the SystemOut.log, shown in Listing 3:

Listing 3
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   The consumer has received 1 message(s).
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   Details for message 1:
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Topic dialect: http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Topic expression, including the namespace prefix: wsntopprefix:dW
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Number of namespace mappings in the topic expression: 2
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   ---- Prefix 'b2' maps to namespace 'http://docs.oasis-open.org/wsn/b-2'
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   ---- Prefix 'wsntopprefix' maps to namespace 'http://wsn.jaxws.dw/topicns01'
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Topic expression, without the prefix: dW
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Message payload: Secure WS-Notification test
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Payload namespace: http://wsn.jaxws.dw.ibm.com
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Payload namespace prefix: dW
[02/03/09 23:32:12:625 GMT] 00000024 SystemOut 
O   -- Payload element name: dWMsg
[02/03/09 23:32:12:641 GMT] 00000024 SystemOut 
O   -- Subscription ID: sub_352c51ee09165308f5817fdc_11fc987b201_5

Congratulations! You’ve worked through the whole scenario.

You can make your WS-Notification messages reliable by associating your WS-Notification service with the WS-ReliableMessaging policy set, which will be covered in a later part of this series. You can configure your WS-Notification service points in a clustered environment with permanent topic spaces, which will also be described in a later part of this series.


Summary

This article explained how to configure the new JAX-WS implementation of WS-Notification with WS-Security in a secured WebSphere Application Server V7.0.

First, the article detailed how to configure WebSphere Application Server’s administrative security. It then listed the key steps to create and configure JAX-WS-based WS-Notification service. Next were instructions on how to create the relevant bindings and associate the policy set and binding with the WS-Notification applications. Finally, a walkthrough scenario demonstrated how to secure sample WS-Notification applications with the WS-Security policy set and binding.


Acknowledgements

I would like to thank Alasdair Nottingham, Brian De Pradine, Bill Dodd, Greg Truty, Henry Chung, James Siddle, Lucas Partridge and Peter Niblett for reviewing this article and providing very valuable comments. Lucas also provided the sample applications.


Download

DescriptionNameSize
Sample application0904_jiang_JAXWSsampleapp.zip711 KB

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=379011
ArticleTitle=WS-Notification in WebSphere Application Server V7: Part 2: Configuring JAX-WS applications with WS-Security for WS-Notification
publish-date=04082009