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:
- Configure WebSphere Application Server V7.0 with administrative security
- Create a Version 7.0 WS-Notification service and a service point in WebSphere Application Server V7.0
Deploy the JAX-WS applications:
- WS-Notification producer and subscriber
- JAX-WS based WS-Notification consumer Web service.
- [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.
Apply the policy set
Username WSSecurity defaultand 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.
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.
There are two ways to enable administrative security: during profile creation, or after profile creation.
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
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
If you have created a profile with security disabled, follow these steps to enable administrative security.
Navigate to the Global security window by selecting Security => Global security. The window in Figure 3 will be displayed.
Figure 3: Global security
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
Step 2 - Select user repository (Figure 5).
Choose Federated repositories, and click Next.
Figure 5: Configure security - 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
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.
- Step 1- Specify the extent of protection (shown in Figure 4).
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.
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:
Navigate to the Buses administrative panel in your WebSphere Application Server instance by selecting Service integration => Buses.
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
WSNBusin this article.
Figure 7: Create a new Service Integration Bus
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.
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
- 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:
Navigate to WS-Notification services in the administrative panel of your WebSphere Application Server instance by selecting Service integration => WS-Notification => Services.
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
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
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
- Step 4.1: Configure service point name.
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
Step 6: Summary.
Click Finish on the summary page, which creates a WS-Notification service and service point.
- Step 1 Configure WS-Notification name (Figure 9).
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
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
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:
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
Select all modules in the application by clicking all check boxes.
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 (
:9443) from the predefined list of Select default HTTP URL prefix, where
your_host_nameis 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
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.
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.
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
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:
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
WSNClientGeneralBindingin this article. Click OK and then save the change.
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
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
To configure the newly created binding:
WSNProviderGeneralBinding, you need to specify the authentication method by configuring the caller settings, which specify the token or message part used for authentication.
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,
Click New to create a caller.
Enter a caller name in the Name field, detailed in Figure 16. This article uses
wsnCalleras the caller name. In the Caller identity local part field, enter the user name token:
The Caller means that this token is selected to create the WebSphere Security Context.
Click OK and then save the changes.
Figure 16: General provider policy set and bindings - Caller
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:
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.
Username WSSecurity defaultpolicy 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
Next weâll attach the
WSNClientGeneralBindingbinding. Choose the resource by clicking on the top checkbox, and select Assign Binding. Choose your client binding from the binding list, such as WSNClientGeneralBinding.
Save your configuration. Figure 18 shows the policy set and binding configuration.
Figure 18: Service client policy sets and bindings - 2
Perform the same operations for
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:
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.
Use the instructions from the previous section to attach the
Username WSSecurity defaultpolicy set and
WSNProviderGeneralBindingprovider binding to the two applications. Figure 19 shows the policy set and binding attachment.
Figure 19: Service provider policy sets and bindings
To attach the policy set Username WSSecurity default and client binding to the WS-Notification service client:
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
WSNSecureServicein this article.
Username WSSecurity defaultpolicy set and client binding, e.g. â
WSNClientGeneralBindingâ, to the
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.
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.
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:
Install WebSphere Application Server V7 with a single server profile with global security enabled (by accepting all default settings). Specify
SecureWsnas your user name and
SecureW5nas your password. Restart your application server.
Unzip the Download and run the example Version 7.0
WS-Notification configuration script by issuing this command to create a version 7.0
<WAS>\bin\wsadmin -f WAS7_WSN_JAXWS_Part2_Setup.py WSNBus WSNSecureService WSNSecureServicePt
Since your administrative security is enabled, when you execute a
wsadmincommand, 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
Alternatively, you can execute the
wsadmincommand 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
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
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
WSNClientGeneralBindingcontains 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.
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
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:/
[Optional step] Configure use of the secure transport protocol by following the instructions detailed in Secure the transport [Optional]
Restart the application server.
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.
In the Web browser for the WSN subscriber, enter the values for the Broker port address, Broker service name and 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
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.
<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.
<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>
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
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
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:
[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.
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.
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.
|Sample application||0904_jiang_JAXWSsampleapp.zip||711 KB||HTTP|
WS-Notification in WebSphere Application Server V7: Part 1: Writing JAX-WS applications for WS-Notification
Application Server V7 Information Center
Application Developer V7 Information Center
Developing a JAX-WS client created from a WSDL file
Developing and Deploying JAX-WS Web services clients
How do I secure applications and their environments?
Creating a new Version 7.0 WS-Notification service
WS-Notification in WebSphere Application Server Version 6.1
OASIS specifications for WS-Notification
developerWorks WebSphere Application Server zone
Get products and technologies