Section 2.

Introduction to message-level security
Transport-level security (e.g. HTTPS) is a point-to-point security model where the channel is protected between two parties. However, many times the service consumer and service provider are separated by intermediaries (e.g. an Enterprise Service Bus). In situations like these, message-level security can provide an end-to-end security solution. Figure 1 depicts how message-level security can provide an end-to-end security solution even if intermediaries are between the consumer and provider. The secret is that with messagelevel security, you can encrypt the message using the public key of the final destination. In this way, only the intended receiver can decrypt the message. Additionally, by encrypting the message and storing the encrypted data into the message, you can store the message on the file system for asynchronous communication and later decrypt it when the receiver is available. These are just a few of the reasons that message level security is often being applied to secure Web services. Figure 1. Comparison of transport level security and message level security (see enlarged Figure 1)

Web Services Security (WS-Security) is an OASIS standard to describe how to implement message-level security with Web services. Specifically, WS-Security describes how you can add confidentiality (e.g. encryption), integrity (e.g. digital signatures), and authentication (e.g. username and password) to a SOAP message. In most cases, XML encryption and XML signatures are the mechanisms for securing the message; WS-Security describes how to use these technologies with Web services to provide message-level security as well as providing a framework for propagating security identities. Figure 2 provides an example of how message-level security looks in a SOAP message. In this tutorial, you learn how to build SOAP messages that get encrypted and signed to provide messages like the one shown in Figure 2. Figure 2. Example of message-level security of a SOAP message (see enlarged Figure

2)

Section 3. Creating and consuming JAX-WS Web services
In this section, you create a simple HelloWorld Web service using a JAX-WS annotation and the Rational Application Developer tooling. Then you use the Rational Application Developer tooling to generate a proxy client to invoke the Web service. Finally, you test your service provider (i.e. Web service) running on the WebSphere Test Environment (WTE) that comes packaged with Rational Application Developer. In your testing, you examine the SOAP messages (i.e. request and response) as they appear on the network.

Creating a JAX-WS Service Provider
In this tutorial, you will use a dynamic Web project to contain the Web service. Start by creating a dynamic Web project and a plain old Java object (POJO) for your service provider as shown in the following steps: 1. Start Rational Application Developer 7.5.2. Click File > New > Dynamic Web Project, then enter HelloWorldProject as the project name, as shown in Figure 3.

Figure 3. Create a dynamic Web project

2. Accept the defaults for the other fields, then click the Finish button. Choose No if
prompted to change to the Web perspective. For this tutorial, you will use the Java EE perspective. 3. Select the HelloWorldProject project in the project explorer view. Right-click and select New > Class, which brings up a Java Class wizard as shown in Figure 4.

Figure 4. Create new Java class wizard

4. Enter com.ibm.dwexample for the package name and HelloWorldProvider as
the class name , and click the Finishbutton.

5. Copy the code from Listing 1 into the HelloWorldProvider.java file and save the
file. Listing 1. HelloWorldProvider.java
package com.ibm.dwexample; import javax.jws.WebService; @WebService public class HelloWorldProvider { public String sayHello(String msg) { System.out.println("[helloworld provider] Hello " + msg); return "Hello " + msg; }

Click the Finish button to deploy and start the Web service on WebSphere Application Server. and then select WebSphere Application Server V7. Rightclick and choose Run As > Run on Server. If you do not have a WebSphere Application Server V7 server defined. you can use Rational Application Developer to deploy your service onto the WebSphere Test Environment (WTE).0 server. Run On Server wizard 2. which displays the Run On Server wizard in Figure 5. Figure 5. Select the Choose an existing server radio button.0 at localhost. Select the HelloWorldProvider.java file that contains the code from Listing 1. you can define a new one by selecting Manually define a new server followed by expanding the IBM folder and selecting the WebSphere Application Server v7. To deploy your service: 1. 3. .} That’s it! A simple POJO with the @WebService annotation is all that is necessary to create a JAX-WS Web service. Now that you have created a Web service.

If prompted to switch to the Java perspective. To create a Java project: 1. Back to top Creating a JAX-WS service consumer Rational Application Developer V7. you use a standalone Java client as your service consumer.5. enter HelloWorldConsumer as the project name and click Finish as shown in Figure 6. Using Rational Application Developer select File > New > Other. you have created a simple JAX-WS Web service. Therefore. .At this point. choose No to stay in the Java EE perspective. In the New Java Project wizard. 2.2 provides a wizard for generating a client from a JAXWS Web service. deployed it to WTE. In this tutorial. and started the service. Locate the Java Project wizard and click Next. Next we’ll create a JAX-WS client that can invoke the running Web service. you begin by creating a simple Java project that will contain your JAX-WS client proxy as well as your client code that uses the generated client proxy.

you can use Rational Application Developer to generate the client proxy classes. Expand the Services folder of the HelloWorldProject Web project. 3.com/}HelloWorldProviderService service and choose Generate > Client as shown in Figure 7.ibm. Right-click the{http://dwexample. .Figure 6. New Java Project wizard Now that you have a Java project to hold the JAX-WS proxy classes that are generated by Rational Application Developer.

Figure 8. Ensure the Web service runtime value in the configuration section is set to IBM WebSphere JAX-WS. as shown in Figure 8.Figure 7. Generate the Web service client 4. and Java Proxyis selected as the client type. Web Service Client wizard . Click the Client project: link to change the client project to use the standalone Java project you created above. 5.

Ensure the Generate portable client checkbox is selected. Figure 9. and then click OK as shown in Figure 9.6. Specify the Client project for proxy 7. It is usually a good idea to segregate the generated code from your client code by using a different package name for the proxy code as shown in this step. Choose HelloWorldConsumer as the client project for the generated Java proxy.clientproxy as the target package of the Web service client. as shown in Figure 10. Click the Next button and enter com.dwexample.ibm. .

Figure 10. . Web Service Client Configuration wizard 8. Click the Finish button to generate the client proxy code. which will look like Figure 11.

To create a Java test client: 1. next you will create a simple Java test client that instantiates the generated client proxy in order to invoke the service provider. All you need to do is instantiate the client proxy and invoke methods you want to be sent to the Web service. or any other low-level programming constructs – the generated classes do this for you.Figure 11. XML parsing.ibm. Figure 11 shows the classes that get generated for you. Using the generated proxy classes.dwexample as the package for the client and ClientTest as the Java class name as shown in Figure 12. . Right-click the HelloWorldConsumer project and choose New > Class. Therefore. Note that you segregate your client code from the generated proxy client by using a different Java package name. Generated client proxy classes Rational Application Developer uses the WSDL of the service provider to auto-generate Java classes that can invoke the service provider Web service. 2. Enter com. you do not have to worry about SOAP message building.

New Java Class wizard 3.ibm. Copy the code from Listing 2 into the ClientTest.clientproxy.clientproxy.ibm.dwexample.Figure 12.HelloWorldProviderService.getHelloWorldProviderPort().ibm. .dwexample. ClientTest. 2 import com. Click the Finish button. HelloWorldProvider port = srv.dwexample.HelloWorldProvider.java file and save the file. 3 import com.java 1 package com. 4 public class ClientTest { 5 6 7 8 public static void main(String[] args) { try { HelloWorldProviderService srv = new HelloWorldProviderService(). Listing 2.

Click the Add button to configure a new monitor to intercept the Web service request and response in order to display the SOAP message. The following section demonstrates how to do this. You can use the following command to invoke it: java –cp com. 2.e.sayHello(“World”)sends a SOAP request message to the listening Web service provider shown in Listing 1. it is generally a good idea to test and verify things. 11 } catch(Exception e) { 12 e. The service provider then sends a SOAP response message back to the client. you use the generated interface (i. 9081) .utils.tcpmon After you have the server-side and client-side up and running. we need to configure the TCP/IP Monitor to listen on an unused TCP/IP port. 4. TCP/IP Monitor view 3.ibm. Finally you use the port object to invoke the sayHello() method which will make a remote call to the Web service provider.out.ws. and then update your client proxy code to point to this TCP/IP port. Rational Application Developer provides a TCP/IP Monitor view to display the SOAP message as it is transferred from the client to the server and back. The invocation of port. Back to top Test and verify the consumer and provider TCPMON is also available with the WebSphere installation. Figure 13. Then locate the TCP/IP Monitor view in theDebug folder and click OK. HelloWorldProvider) to get a handle to the Web service port.ibm. Let’s examine what these SOAP request and response messages look like via the built-in TCP/IP Monitor view provided by Rational Application Developer.0. Right-click in the first entry box and choose Properties as shown in Figure 13.printStackTrace(). Enter an unused TCP port for the Local monitoring port field.webservices. Then in line 8. 10 System.engine.webservices.jar com. In Rational Application Developer.ws.thinclient_7.9 String resp = port. (e. line 7 demonstrates how you instantiate the client proxy service that Rational Application Developer generated for you.g. To use this view. select Window > Show View > Other.0. 1. 13 } 14 } 15 } In Listing 2.println("[response] " + resp).sayHello("World").

You can accomplish this by . Enter the TCP port for the Web service provider (check the WSDL in the HelloWorldConsumer project). New Monitor settings 7. 8.g. Click the OK button. Enter localhost for the Host Name field.5. 6. Start TCP/IP Monitor Now that the TCP/IP Monitor is running and listening for Web service calls. (e. you need to change your client proxy to connect to the listening port of the TCP/IP monitor instead of connecting directly to the service provider. 9080). You should have values similar to Figure 14: Figure 14. Now select your newly defined TCP/IP Monitor and click the Start button as shown in Figure 15: Figure 15.

9081) as shown in Figure 16. ClientTest results (see enlarged Figure 71) At this point. Let’s discuss the differences in policy set terminology: • Policy – A policy describes a configuration that defines qualities of service (QoS) for Web services. The results should appear in the TCP/IP Monitor view as shown in Figure 17. Section 4. • Policy sets – A policy set is a collection of policies.e. 9.g. server-side) and a JAX-WS Web service consumer (i. and once again view the results in the TCP/IP Monitor view to verify that the SOAP message is being passed securely. you configure the policy sets to add message-level security to your little HelloWorld example. .java file and choose Run As > Java Application. Policy sets Policy sets provide a declarative way to define qualities of service (QoS) for Web services.wsdl file located in the HelloWorldConsumer project under the src > META-INF > wsdl folder path and choose Open With > WSDL Editor. you have developed a JAX-WS Web service provider (i. WSDL Editor (see enlarged Figure 16) 11.changing the port number in the WSDL that was saved locally to the client project as a result of clicking the Generate portable client checkbox in Figure 10. This simplifies the management of multiple Web services as policy sets can be reused across them. Right-click the HelloWorldProviderService. In the next section. Figure 16.e. Right-click the ClientTest. client-side) and demonstrated the results of the consumer invoking the provider. Examples include WS-Security and WS-Addressing. Change the port number to match the TCP/IP Monitor listening port (e. Figure 17. then save and close the WSDL file. 10.

a user has a pair of cryptographic keys—a public key and a private key.2.5. For production Web services. Figure 18.5. Bindings – Policy sets are meant to be reused across Web services and thus do not contain environment specific settings such as key stores or passwords.• • Policy set attachment – In order to apply policy sets to Web services. also known as asymmetric cryptography. WebSphere Application Server V7 does support exporting policy sets and policy set bindings such that you can import them into Rational Application Developer 7. The private key is kept secret. but the private key cannot be practically derived from the public key. server).2 also comes prepackaged with a set of policy sets. but these are for demonstration purposes only.2 fully supports configuration of the client-side bindings required for policy sets. However. you should customize the policy set bindings as shown in this tutorial.wikipedia. while the public key may be widely distributed. After importing into Rational Application Developer. a binding contains these environment specific values.org/wiki/Public-key_cryptography) . Incoming messages would have been encrypted with the recipient's public key and can only be decrypted with his corresponding private key.5. The keys are related mathematically. Rational Application Developer 7.e. you must configure server-side policy set bindings from the WebSphere Application Server V7 server.e.” (http://en. WebSphere Application Server V7 also comes with 4 sample bindings. they need to be attached. Instead. you can attach the policy sets and policy set bindings to the service provider (i. as well as the service consumer (i. Setting up asymmetric keys “Public-key cryptography. Rational Application Developer 7. In public key cryptography. Example of policy sets (see enlarged Figure 18) WebSphere Application Server V7 comes prepackaged with 18 policy sets (see Figure 18) to simplify getting started. client). using the wizards in Rational Application Developer. is a form of cryptography in which the key used to encrypt a message differs from the key used to decrypt it. They are production-level policy sets that you can begin using immediately.

cd c:\Program Files\IBM\SDP\runtimes\base_v7) 3. Additionally.C=US" -keypass passw0rd This command generates a public key and private key pair that will be accessed via the server1 alias. select Start > Run…. In this section. (e.g. First. The first thing you need to do is create a key store to hold your public and private keys. • Signer certificate – After your digital certificate has been signed by a CA.jks -storepass f00bar -dname "cn=server1.O=IBM. which is password protected. you can use asymmetric keys. GoDaddy) to sign your key. the private key stays with the owner and should not be distributed.e. Both private and public keys are stored in the helloServerKeys. Then you create the client-side keys for your service consumer running as a standalone client from Rational Application Developer V7. but for this tutorial you use the keytool command provided by the Java Development Kit (JDK). this command self signs the public key. serverside) running on WebSphere Application Server V7. In Microsoft Windows. Also called a key ring. Before you get started.To secure your Web services. Now run the following keytool command: java\bin\keytool. This key should not be shared with others. you learn how to create a set of cryptographic keys that you then use to secure your Web service. your name) and send this digital document to a CA to sign for you. 2. 4.exe –export -v -alias server1 –file c:\temp\server1. change directories to where WebSphere Application Server V7 is installed. you create a digital certificate which contains your public key along with your identity information (e. you can trust others by the CA vouching for you and them. • Private key – The key that matches your public key and is used to decrypt data that others have encrypted with your public key. • Certificate authority – For others to trust that your public key really belongs to you. We purposely separate the server-side keys from the client-side keys to delineate the differences and to mimic the more likely production environment where the consumer and provider are often distributed on different physical hardware. it may be helpful to review the following terminology: • Public key – The key that is used by others to encrypt data for you. • Key store – A place to store your keys. This can be accomplished with the following keytool command: 1. Back to top Creating service provider keys There are a number of tools for creating public key/private key pairs. you normally request a CA (e. you create the server-side keys that will be used by your service provider (i. Since others do the same thing. In other words. public key certificate. since it will be available with standalone clients as well as with WebSphere Application Server.jks file.exe -genkey –v -alias server1 -keyalg RSA -keystore helloServerKeys.2. Verisign. with the followingkeytool command: java\bin\keytool.jks –storepass f00bar . then enter cmd in the Open field of the dialog box and click OK. and signer certificate are often used synonymously. it becomes a signer certificate.g. In the Command Prompt window.5. • Digital certificate – To share your public key with others and for them to trust that you are who you say you are. GeoTrust. Digital certificate. Next.cert –rfc -keystore helloServerKeys.g. you need to export your server1 certificate to be imported into your client-side key ring later on.

This public key certificate will then be imported into the service consumer’s (i. Then you can decrypt the message using your private key.jks -storepass g00ber -dname "cn=myclient. then enter cmd in the Open field of the dialog box and click OK.e.exe -genkey –v -alias myclient -keyalg RSA -keystore myclientKeys. The export argument of the keytool does just that. you must somehow extract your public key from your key ring into some format and send it to the party with which you wish to securely communicate. In Microsoft Windows. server1 at IBM and myclient at ACME) to demonstrate that your keys can be from completely different organizations and that the client and server need not have keys created by one certificate authority. Now run the following keytool command: jdk\bin\keytool. Only when you exchange public keys with each key store is a trust relationship established. you can use the keytool command to create the client-side key ring. In fact.For someone (or some computer) to encrypt messages for you. client-side) key store such that the service consumer will know how to encrypt messages for the service provider. they need your public key. Note that you will use thekeytool command that comes with Rational Application Developer V7.cert.g. However. Figure 19 shows the commands used for creating the service provider keys: Figure 19. (e. change directories to where Rational Application Developer 7. In the Command Prompt window.C=US" -keypass p@ssword Just as the service provider used this command to generate a public key and private key pair. and in the above command saves the public key into an X509 digital certificate format and stores it in the text file c:\temp\server1. As with the server-side keys. select Start > Run….5. next you create a client-side key store.2 is installed.e.5. Note that this is a completely different set of keys and has no relationship to the server-side keys.O=ACME. 2. Service Provider Key setup Back to top Creating service consumer keys Now that you have created the server-side keys. our keys use a different organization name (i. cd c:\Program Files\IBM\SDP) 3. we now use the same command to create the service consumer’s key ring with a corresponding set of public key/private key that is accessed via .2 and not the WebSphere Application Server keytoolas evident by the different directories from which you run this command: 1.

note that the service consumer (i. 1. 4.e.jks –storepass g00ber This command imports the public key certificate into the service provider’s (i. Then.e. Next you import the server-side public key into the client-side keys using the following keytool command: jdk\bin\keytool.e myclientKeys. Figure 20 shows all of the commands listed above required to create the client-side keys: Figure 20.the myclient alias. Creating client-side keys with keytool Back to top Importing service consumer keys Recall during the service provider key creation. 5.jks file. this command creates a self-signed public certificate that contains the public key.e.jks). The following keytool command lets you import the public key into the key ring: .cert –rfc -keystore myclientKeys.exe –import -v –noprompt -alias server1 –file c:\temp\server1. server-side) key store so that the service provider will know how to encrypt messages for the consumer. the WS-Security configuration associated with the client will specify the server1 alias public key in the client’s key store. Likewise with the service provider keys. However. you had not yet created the service consumer keys with which to export and import into the service provider’s key ring. you need to import this public key into the client-side key store (i. This is done with the following keytool command: jdk\bin\keytool. you need to export the client certificate to be imported into the service provider’s key store. client-side) wants to encrypt a message for the service provider. client-side) keys are stored in themyclientKeys. you can now import this key into the service provider key ring.exe –export -v -alias myclient –file c:\temp\myclient. which is the key pair that is associated with your service provider.jks –storepass g00ber Recall above that you exported the public key of the server1 alias.cert -keystore myclientKeys. Therefore. To build that trust level between the service provider and service consumer. when the service consumer (i. Now that you have created the client-side keys and certificates and exported the public key to be used by the service consumer.

You will use these keys in the configuration of the WSSecurity policy set to provide encryption and signing. In this tutorial. the timestamp. Rational Application Developer 7.e.java\bin\keytool. you will copy the Username WSSecurity default policy set. these policies specify message authentication by using the username token. This location will also work for a standalone server configuration. Message confidentiality is achieved by encrypting the message body. Within these policies. right-click your WebSphere Application Server V7 runtime in the Servers view and choose Administration > Run administrative console. 1.2 allows attaching policy sets and customization of clientside bindings.jks profiles\<profile name>\config\cells\<cell name> On my machine the path is C:\Program Files\IBM\SDP\runtimes\base_v7\profiles\was70profile1\ config\cells\griffith-t60pNode01Cell\MyKeys. From the WebSphere Application Server V7 directory. copy the service provider’s key ring to the following directory: copy helloServerKeys. you will point to this key store.cert -keystore helloServerKeys. 2. Ensure your WebSphere Application Server V7 runtime is started or Run administrative console will be grayed out. Very often the preconfigured policy sets are more than adequate for most needs and thus copying one of the built-in policy sets and modifying it is often easier than starting from scratch – it is also the recommended approach. but does not allow customization of policy sets. All of the work of specifying what parts of the message to sign and encrypt are already done for you by copying the Username WSSecurity default policy set. Back to top Creating a policy set WebSphere Application Server V7 allows creating policy sets from scratch to provide maximum flexibility.exe –import -v –noprompt -alias myclient –file c:\temp\myclient. In your policy set bindings configuration below. the signature. The Username WSSecurity default policy set comes with a WSSecurity policy and a WSAddressing policy. you need to open the Administration Console of WebSphere Application Server. and the username token. From Rational Application Developer. the addressing headers. Now you have the client keys and the server keys both with an imported certificate from the other. In this tutorial.jks –storepass f00bar Make sure you run this command from the WebSphere Application Server V7 directory (i. Launching Administration Console from Rational Application . To create and customize a policy set. you copy it to the cell configuration directory of the WebSphere Application Server V7 runtime so that your keys will be available on all nodes of a cluster for a clustered environment. you specify message integrity by digitally signing the message body. Figure 21.5. and the username token. you use the WebSphere Application Server that we installed inside of Rational Application Developer. c:\Program Files\IBM\SDP\runtimes\base_v7) Now that the service provider’s key ring is ready. as shown in Figure 21. but WebSphere Application Server V7 also comes with many preconfigured policy sets to simplify their creation. Finally.

the signature. and the Username token. select Services > Policy sets > Application policy sets as shown in Figure 22. The Username WSSecurity default policy set encrypts the SOAP body. the timestamp. you will use this policy set for this tutorial. .Developer 2. and the Username token. From the Administrative Console. Application policy sets (see enlarged Figure 22) 3. the Username WSSecurity default policy set signs the SOAP body. the addressing headers. Figure 22. Message authentication is provided using the Username token. As this policy set provides defaults that are likely to be used frequently in real-life scenarios. Additionally. Click the checkbox next to the Username WSSecurity default. then click the Copy… button.

select Services > Policy sets > Application policy sets as shown in Figure 22. Enter HelloWorldPolicySet as the name for your new policy set and any description you’d like in the description field. You can then export the policy set to allow the consumer to use the same policy set. Click the OK button to save the file. Figure 24. . Additionally. but you need to assign a binding to specify the service-specific settings to use. you copy the provider sample bindings and then customize it. Click the OK button. From the Administration Console. Rational Application Developer does not allow customization of policy sets and thus you used the Administration Console of WebSphere Application Server to create the policy set.Figure 23. Click the HelloWorldPolicySet. Rather than starting from scratch. you may attach the policy set to the service provider or service consumer using Rational Application Developer such that the policy set will get attached when deployed from Rational Application Developer. Click the checkbox next to the HelloWorldPolicySet then click the Export… button. such as key stores. 2. Back to top Exporting a policy set As discussed previously. as this is usually easier and considered a best practice. Copy policy set (see enlarged Figure 23) 4. Exporting policy sets (see enlarged Figure 24) 3. Back to top Creating a policy set binding The policy set defines the policies to attach to your service provider.zip link as shown in Figure 24 and save the file to c:\temp. 1.

5. as shown in Figure 25.g. To customize the policy set binding to specify which certificates you trust: 1. . 3. For simplicity in this tutorial. Back to top Configuring service provider policy set binding The provider sample that you started with is for demonstration purposes only. expand the Policy sets folder and select the General provider policy set bindings link. In the Services menu. then click the Copy… button. Copy policy set bindings for customization (see enlarged Figure 25) 4. Navigate to the Keys and certificates policy bindings by clicking HelloWorldProviderBindings > WS-Security > Keys and certificates. Enter HelloServerTrustStore in the name field then click the External keystore radio button. MY_KEY_STORE) that would point to the absolute path so that you wouldn’t need to change your policy set bindings when moving from one cell to another.jks for the full path to the external key store. Normally. 6. 2. Enter f00bar as the key store password. 3. Enter HelloWorldProviderBindings as the name for the new bindings and any desired text for the description field (optional). we use the hard-coded path to the key store.1. Enter ${USER_INSTALL_ROOT}\config\cells\<yourCellName> \helloServerKeys. 4. Click the checkbox next to the Provider sample policy set bindings. Figure 25. 2. you would create a new WebSphere variable (e. This link displays the list of provider policy set bindings. Scroll down the page to the Trust anchor section and click the New… button. Your screen should look something like Figure 26. you now need to customize your new policy set binding by changing the sample keys to use the real keys that you generated above. Select JKS as the key store type. Click OK. and you must change the keys to provide production-level security. Therefore.

you use your server-side key store as your trust store to simplify things.g. To customize the signing token for inbound messages to use this trust store: 1. This token essentially verifies that the key used to sign the message is a trusted key. GeoTrust) that have signed the public keys. 7. This step lets you verify that the public certificate that is used to encrypt messages is a trusted certificate. In this tutorial. Now that you have specified your trust store. you customized the policy set binding to specify which certificates you trust. your trust store would contain trusted CAs (e. you can customize the signing token for inbound messages to use this trust store. In this step. Normally. This step displays a window like the one in Figure 27.jks. Navigate to the Authentication and protection bindings by clicking HelloWorldProviderBindings > WS-Security > Authentication and protection. Click the OK button to save the changes. . New trust anchor On my machine the external key store path is C:\Program Files\IBM\SDP\runtimes\base_v7\profiles\was70profile1\config \cells\griffith-t60pNode01Cell\helloServerKeys. Verisign.Figure 26.

Figure 27. Change the Certificate store to be (none) instead of DigSigCertStore. 4. Figure 28. Click the OK button again to save the consumer signature token customizations. Customizing policy set bindings (see enlarged Figure 27) 2. you need to customize the token to be used for signing outgoing messages: To customize the token for signing outgoing messages: . which should now bring you back to theAuthentication and protection page shown in Figure 27. Click the OK button to save the callback handler customizations. Changing certificate store (see enlarged Figure 28) 3. Now that you have specified what trust store to use for verifying the signature for incoming messages. Then choose HelloServerTrustStore next to the Trusted anchor store label as shown in Figure 28. Select con_signx509token > Callback handler.

7. 5.c=US server1 passw0rd Keystore type Keystore password Key name Key alias Key password 3. you should be back at the Authentication and protectionpage shown in Figure 27. 6.1. which is used to decrypt incoming messages. Select con_encx509token > Callback handler. You will begin with the con_encx509token token. Change the values to match this table: Field Keystore path Value ${USER_INSTALL_ROOT}\config \cells\<yourCellName> \helloServerKeys. Change the values to match this table: Field Keystore path Value ${USER_INSTALL_ROOT}\config \cells\<yourCellName> \helloServerKeys. At this point. To customize the binding for encryption and decryption protection: 1. 2. Then choose Custom from the drop-down in the Key store section followed by clicking the Custom keystore configuration link.jks JKS f00bar cn=server1.o=IBM. Now that you have customized the binding for signatures. Click the OK button to save the key store configuration changes. Then choose Custom from the drop-down in the Key store section and click the Custom keystore configuration link. you must specify the password for the private key. Click the OK button to save the token changes. Click the OK button to save the callback handler changes. Select gen_signx509token > Callback handler. next you customize the binding for encryption and decryption protection. Note that since you use the private key of server1 for outgoing signatures. 2. 4.jks JKS Keystore type .

Notice that you have to enter the key’s password in addition to the key store password since you are accessing the private key.o=IBM. . 5.c=US server1 passw0rd 4. f00bar cn=server1. 6. The results should look similar to Figure 29.Keystore password Key name Key alias Key password 3.

Key store for consumer decryption 7. 2. To customize the token used for encrypting outgoing messages: 1.jks . 8. Click the OK button to save the key store configuration changes. Click gen_encx509token > Callback handler. Change the values to match this table: Field Keystore path Value ${USER_INSTALL_ROOT}\config \cells\<yourCellName> \helloServerKeys. At this point. you should be back at the Authentication and protectionpage as in Figure 27. Click the OK button to save the callback handler changes.Figure 29. Click the OK button to save the token changes. Then choose Custom from the dropdown in the Keystore section and click the Custom keystore configuration link. 9.

you can also export the policy set bindings. Back to top Exporting a policy set binding Just as you exported the copied policy set above. Click the HelloWorldPolicySet. Figure 30. you will use Rational Application Developer V7. you now need to export the policy set and bindings to import them into Rational Application Developer. Click the OK button to save the token changes. While WebSphere Application Server V7 provides the ability to attach policy sets and bindings to services in the Administrative console. Click the checkbox next to the HelloWorldProviderBindings policy set bindings. 3. then click the Export… button. Because this policy set binding is only for the service provider (i. 6. it isn’t necessary to export this policy set binding.2 to accomplish this task.Keystore type Keystore password Key name Key alias 3. At this point. In the Services menu. JKS f00bar cn=myclient. doing so allows you to attach the binding to the service provider in Rational Application Developer. However. you should be back at the Authentication and protectionpage as in Figure 27. expand the Policy sets folder. 7. Click the OK button to save the callback handler changes. 1. So far you have created a custom policy set and a custom policy set binding and customized to use custom keys.c=US myclient 4.5. server-side).e.zip link as shown in Figure 30 and save the file to c:\temp. Click the OK button to save the file.o=ACME. 2. Click the OK button to save the key store configuration changes. which simplifies policy set attachment during development. Select the General provider policy set bindings link to display the list of provider policy set bindings. Therefore. 5. Notice that in this case you do not need to provide a password for the key alias because you are using the client’s public key to encrypt the outgoing response message. for this tutorial. Export policy set bindings .

then click the Finish button. Click the Browse… button and choose the HelloWorldProviderBindings. As in the steps above. 5.zip file that you exported to c:\temp above. 3. 2. Recall that policy sets provide a declarative way to provide qualities of service (QoS) for Web services. The wizard reads the zip file and lists the policy sets included in the file.zip file that you exported to c:\temp above. By attaching a policy set and binding to a Web service. the wizard reads the zip file and list the policy set bindings included in the file. Figure 31. 1. Click the checkbox next to HelloWorldPolicySet. which displays a dialog box like the one in Figure 31. .Section 5. 6. which displays a dialog box like the one in Figure 32. then click the Finish button. From the main menu of Rational Application Developer choose File > Import > Web services > WebSphere Policy Sets. Now click the Next button. right-click HelloWorldProject and choose Import > Import > Web services > WebSphere Named Bindings. Again. Click the checkbox next toHelloWorldProviderBindings. Securing the service provider Now that you have created a custom policy set and policy set binding (which you exported to c:\temp) you need to import them into the HelloWorldProject to attach them to the service provider. Click the Browse… button and choose the HelloWorldPolicySet. Import policy set 4. Now click the Next button. you are declaratively specifying what QoS to use.

com}HelloWorldProviderService then right-click and choose Manage policy set attachment…as shown in figure 33: Figure 33. . Click the Add button add a policy set and binding to an endpoint. In Rational Application Developer.Figure 32. 7. you can attach them to the service provider. Attaching policy set and bindings 8. Leave the scope set to the entire service and choose HelloWorldPolicySet from the drop-down for the policy set andHelloWorldProviderBindings from the drop-down for the binding as shown in figure 34. Import policy set bindings Once the policy set and bindings have been imported into Rational Application Developer.ibm. 9. drill into the HelloWorldProject > Services > {http://dwexample.

Customizing policy set bindings 10.Figure 34.0 server configuration (see . Click the Finish button to close the policy set attachment dialog box. Right-click WebSphere Application Server v7.0 at localhost (or whatever your server is called if different) and chooseOpen. WebSphere Application Server V7. you will deploy the service provider onto the WebSphere Application Server runtime and verify that our policy set and bindings have been attached. Figure 35. Click the OK button to save this association. but in this tutorial we will use the Add and Remove Projects… menu item available in the Rational Application Developer Servers view. 11. Now that you have attached the policy set and bindings to the service provider. To deploy the service provider: 1. There are a variety of ways to deploy the service provider onto the WebSphere Application Server. This will bring up the server configuration settings page as shown in Figure 35.

0 at localhost in the Servers view and choose Remove as shown Figure 36. Save and close the server configuration file. 3. In order to ensure a clean deploy.enlarged Figure 35) 2. 4. then re-add it. Right-click the HelloWorldProjectEAR project under WebSphere Application Server v7. Ensure Run server with resources on Server is selected in the Publishing settings for WebSphere Application Server section. you will remove the HelloWorldProjectEAR from the server. The Run server with resource on Server setting will ensure that the policy set and bindings attachment show up in the WebSphere Application Server Administrative Console. Remove HelloWorldProjectEAR from server . Figure 36.

Now that the project has been removed. Figure 37. Deploy Service Provider to WebSphere Application Server 7. You should see the HelloWorldProviderServicelisted in the service providers. 5. you will add it back.0 at localhost (or whatever your server is called if different) and chooseAdd and Remove Projects… as shown in Figure 37. 10. 9. Login to the admin console and select Services > Services providers.0 at localhost. 8. 6. When the server finishes deploying and publishing. which will cause a fresh deploy. You should now see the HelloWorldPolicySet attached as the policy set and HelloWorldProviderBindings attached for the binding as shown in Figure 38. Right-click WebSphere Application Server v7. Click the HelloWorldProjectEAR project from the Available projects field and click the Add > button to move it to the Configured projects field then click the Finish button. but this time choose Administration > Run Administrative console. . Click the HelloWorldProviderService to drill into this service. Once again right-click WebSphere Application Server v7. use the Administrative Console to verify that the service provider was successfully deployed to WebSphere Application Server and that the policy set and bindings have been attached.

. Verify policy set and bindings attached (see enlarged Figure 38) If you do not see the HelloWorldProviderService in the service providers window. In the Administrative Console. navigate to Security > Global security and verify that Enable administrative security andEnable application security are selected as shown in Figure 39.Figure 38. Since you copied the Username WSSecurity default policy set. you need to enable security on the WebSphere Application Server server such that authentication can occur. To enable security on WebSphere Application Server: 1. As a result. this policy set defines authentication through the username token. then logout of the Adminstrative Console and then log back in to refresh the console such that you see the policy set and bindings attached to the service provider as shown in Figure 38.

Figure 39. If security was not enabled before. Enable application security (see enlarged Figure 39) 2. Therefore. you should have the service provider running on WebSphere Application Server V7 with the customized HelloWorldPolicySet and bindings attached. The following sections describe this process.e. you need to restart WebSphere Application Server for the security settings to take effect. you do the same thing with the service consumer. Attaching a policy set In a similar fashion to attaching the policy set to the service provider. Section 6. client-side) and customize the consumer bindings to match up with the expectations of the service provider. If you were to rerun the service consumer as developed above. To configure the consumer-side binding for signatures: . it is also available to be attached to our service consumer. which is what we’ll do in this tutorial. the service provider would reply with a SOAP fault indicating that the consumer does not adhere to the policy set attached to this provider. Consuming a secure service At this point in the tutorial. you need to attach a policy set to the consumer (i. One way to ensure the consumer adheres to the policy of the service provider is to use the same policy set. Since you imported the HelloWorldPolicySet into Rational Application Developer to attach it to the service provider.

Attaching policy set 3. .com}HelloWorldProviderService. Select the WSSecurity policy type in the bindings configuration section.1. 5. Figure 40. which presents the dialog box shown in Figure 40. Type HelloWorldConsumerBinding in the drop-down binding field and click OK. Click the Configure… button.ibm. Drill down to HelloWorldConsumer > Services > Clients > {http://dwexample. which presents the WSSecurity Binding Configuration dialog as shown in Figure 41. Right-click and choose Manage policy set attachment… 2. Click the Next button followed by the Add… button of the Application section. Select HelloWorldPolicySet for the policy set drop-down. 4.

Enter the values in the following table for the Key Store Settings dialog shown in Figure 42. 7.jks Keystore passwordg00ber JKS Keystore type .Figure 41. Field Keystore path Value C:\Program Files\IBM\SDP \myclientKeys. Select the Digital Signature Configuration tab. WSSecurity Binding Configuration (see enlarged Figure 41) 6. and then click the Key Store Settings… button of the Outbound Message Security Configuration section.

service request) message using the private key of the myclient alias. myclient p@ssword Figure 42. 11. In the Inbound Message Security Configuration section. you will configure the keys to use for encryption. Now you have configured the consumer-side binding for signatures. Outbound signature key settings 9. Enter C:\temp\server1. Notice that you are specifying that you want to sign the outbound (i.e. 12.cert as the value for the Certificate Path field. 10.Key alias Key Password 8. because we only want to trust the signature if the response is from the server. Click the OK button. To configure the keys to use for encryption: . uncheck the Trust Any Certificate. Click the OK button. Click the Key Store Settings… button. then enter the values in the following table: Field Keystore path Value C:\Program Files\IBM\SDP \myclientKeys. Next. 15.jks Keystore passwordg00ber JKS Keystore type 13. 14.

Enter the values from the following table for the Key Store Settings dialog shown in Figure 43. On the XML Encryption Configuration tab. 2. 5.1. To configure how to decrypt the inbound message (i. and then click the Key Store Settings… button of the Outbound Message Security Configuration section. the response): 1. Click the OK button. Outbound encryption key settings 4. Since you are encrypting the service request for the service provider. 2.jks Keystore passwordg00ber JKS Keystore type server1 Key alias 3. Figure 43. click the Key Store Settings… button in the Inbound Message Security Configuration section. you specify the public key of server1 in Figure 44.e. Enter the values from the following table for the Key Store Settings dialog shown in Figure 44. Select the XML Encryption Configuration tab. Field Keystore path Value C:\Program Files\IBM\SDP \myclientKeys. Field Keystore path Value C:\Program Files\IBM\SDP . which is associated with the server1 certificate.

Select the Token Authentication tab then choose the com. Click the OK button. 6. \myclientKeys. Enter a valid user name and password that matches the user repository of your WebSphere Application Server (e.UNTGenerateCallbackHand ler as the callback handler. 7.Keystore passwordg00ber JKS Keystore type myclient Key alias p@ssword Key password 3.jks Figure 44. Click the Add Timestamp checkbox. 5. You will choose the UNTGenerateCallbackHandler.g. it will be encrypted with the client’s public key. 9. Inbound encryption key settings 4. Click the Add Nonce checkbox. Somehow you need to get a valid username token in the SOAP header for the server to verify that you are authenticated before executing the service provider Web service.ibm. . When the provider’s response comes back. as Figure 45 shows. Therefore. admin/admin).callbackhandler. which is what we have specified in Figure 44.wssecurity. The Token Authentication tab provides two such methods. you need to decrypt the message using the client’s private key. 8.websphere. Recall that the Username WSSecurity default policy set that you copied included authentication using a username token.

1. Testing secure JAX-WS In section 3 of this tutorial. you now need to rerun the test and verify that the SOAP messages contain encrypted data that isn’t visible to anyone except the intended recipient (not even the TCP/IP Monitor that is acting as an intermediary).e. you tested the service provider and consumer and viewed the SOAP messages as they traveled between the client and server. then right-click the ClientTest. . As one of the goals with message. This should present a Run Configurations dialog box as shown in Figure 46. and then click the Finish button. Click the OK button. Figure 45. only the intended recipient can see the data inside the SOAP message).java file of the HelloWorldConsumer project and choose Run As > Run Configurations.5. you will need to ensure you are using Rational Application Developer 7.10.level security is to ensure confidentiality (i. Section 7. and thus the SOAP messages were sent in clear text (i.2 . Ensure the TCP/IP Monitor is started as shown in Figure 15.e. In section 3. you had not yet enabled message-level security through the attachment of policy sets. Token authentication (see enlarged Figure 45) If the dialog box as shown in Figure 45 does not include checkboxes for Add Timestamp and Add Nonce. not encrypted) as shown in Figure 17.

you need to specify the following VM argument: -Djava. Next click the Run button and view the results in the TCP/IP Monitor view.security.login. Since the consumer needs to use a Java Authentication and Authorization Service (JAAS) to pass in the Username credentials.Figure 46. Setting ClientTest arguments (see enlarged Figure 46) 2. which looks something like Figure 47. Viewing the SOAP messages with XML encryption (see enlarged .config= ”C:\Program Files\IBM\SDP\runtimes\base_v7 \profiles\was70profile1\properties\wsjaas_client. Figure 47.conf” 3.auth.

before once again testing the client and server pair. Then we showed you how to build a matching consumer and how to test the client.Figure 47) Notice that the Console shows the output from the consumer after unencrypting the message. Section 8.to-server communications. we showed you how to monitor the data flowing between the client and the server. Conclusion In this tutorial. If you view the WebSphere Application Server console log. Acknowledgements Special thanks to Zina Mostafa and Indran Naick for reviewing this tutorial. . which we showed you how to customize with personalized asymmetric keys. we demonstrated how to create a custom policy set. you see a similar message. the steps taken are valid production-level configuration options that employ strong cryptography for encryption and protection. which demonstrates that the service provider received the message. Additionally. While this tutorial was designed to teach and instruct. and verify that in fact the SOAP messages are being encrypted and protected by the customized policy set you created and associated with the service consumer and provider pair. Next. we demonstrated how to create a Web service provider using JAX-WS annotations.

Sign up to vote on this title
UsefulNot useful