Web Services Secure Conversation interoperability between WebSphere Application Server V8 and

Windows Communication Foundation using dynamic policy configuration, Part 1:

Configure and test WS-SecureConversation

Tom LinkAdvisory Software EngineerWeb Services InteroperabilityIBM, Research Triangle Park, NC

Hyen-Vui (Henry) ChungSoftware EngineerAmazon, Austin, TX

Charles Le VaySenior Software EngineerWebSphere Technical EvangelistIBM, Research Triangle Park, NC

Salim ZeitouniAdvisory Software EngineerWebSphere Commerce DevelopmentIBM, Research Triangle Park, NC

September, 2011

© Copyright International Business Machines Corporation 2011. All rights reserved.

This series of articles describes how to use the IBM WebSphere Application Server V8 Endpoint Interface samples to demonstrate interoperability with Microsoft™ Windows™ Communication Foundation. The series provides step-by-step configurations to show you what you need to do for SOAP message security interoperability using WS-Secure Conversation.

The article is intended for Web services developers and architects who plan to develop Web services across these platforms. You should have a basic understanding of Java™ programming, Web services development, WSDL and SOAP.

Web Services Secure Conversation interoperability between WebSphere Application Server V8 and Windows Communication Foundation using dynamic policy configuration, Part 1: ........................................................................................................... 1 Introduction .......................................................................................................................... 2

Scenario overview ................................................................................................................ 2 Getting started ...................................................................................................................... 4 Create interoperable policy sets and general bindings ......................................................... 6 Configure the EchoService consumer, provider and trust services ................................... 35 Get the WSDL .................................................................................................................... 41 Test the EchoService .......................................................................................................... 43 Summary ............................................................................................................................ 44 Resources ........................................................................................................................... 45

Introduction

WebSphere Application Server V8 (hereafter called Application Server) includes a set of Java API for XML-Based Web Services (JAX-WS) samples that demonstrate simple message exchange patterns (MEPs) using both a synchronous and asynchronous programming model. The samples support SOAP 1.1 and SOAP 1.2. Using these MEP samples composed with Web services standards such as WS-Addressing (WS-A), WS-Security, WS-Reliable Messaging (WS-RM), and WS-Secure Conversation (WS-SC), you can perform a broad range of interoperability tests. These samples demonstrate the use of JavaBean artifacts, static service endpoints and proxy-based clients.

The purpose of this series of articles is to highlight protocol-level interoperability between WebSphere Application Server V8 and Windows Communication Foundation 4.0 (WCF) using dynamic policy to configure WS-SecureConversation. Dynamic policy configuration is a new feature in WebSphere Application Server V8.

In this series of articles, you’ll learn how to:1. Statically configure a custom WebSphere WS-SC policy set based on a policy set

from the default repository, and modifying Provider sample and Client sample bindings.

2. Dynamically configure an Application Server web services client using the WS-Security Policy assertions emitted from WebSphere and test it with a the WebSphere Application Server service provider

3. Dynamically configure a Windows Communication Foundation client using the WS-Security Policy assertions emitted from WebSphere and test it with the Application Server service provider.

Part 1 focuses on statically configuring a custom WebSphere WS-SC policy set and binding.

Scenario overview

The Web Services Secure Conversation Language specification is built on top of the WS-Security and WS-Policy models to provide secure communication between services. The WS-Secure Conversation (WS-SC) specification defines mechanisms for establishing and

sharing security contexts, and deriving keys from security contexts, to enable a secure conversation. One benefit of WS-SC over WS-Security is that messages are encrypted using a symmetric encryption algorithm, which is much more computationally efficient than the asymmetric encryption algorithm used in WS-Security. WS-SC includes the concept of session-oriented security, which lends itself to a symmetric algorithm as opposed to WS-Security, which is designed to provide security on a message-by-message basis.

There are two parts to establishing a WS-SC message exchange. The first part is called the bootstrap. During the bootstrap, a Web service client establishes a Security Context Token (SCT) from a Security Token Service (STS) that is trusted by the corresponding Web service. Once the SCT is established, the client can then securely exchange messages with the Web service using a derived key that is based on this SCT and that can be used for signing and/or encrypting messages. We’ll refer to this second part as the application flow.

The bootstrap request for an SCT issued from an STS needs to be protected so that the established token is not compromised. In our example, the client encrypts and secures (message integrity) the SCT request and related operations for the recipient (STS) using X.509 tokens. The responses to the client from the STS are also encrypted and secured using X.509 tokens.

In this article, you’ll learn how to define a WS-SC configuration that can interoperate with Microsoft WCF. First we’ll define the static WebSphere custom policy set and custom binding using the Application Server V8 policy set administration. Application Server V8 ships with an updated set of customizable policy sets and bindings. In this article, you’ll learn how to modify the policy sets and bindings to support the security requirements of this scenario. You’ll then use the SEI samples to test the WS-SC configurations.

This scenario uses the provided test certificates for both the WebSphere and Microsoft implementations. The certificates represent the typical “Bob and Alice” structure used in many security scenarios. In this scenario, Bob is associated with the service and Alice is associated with the client.

The scenario calls for all outbound SOAP messages to be signed and encrypted. It also calls for WS-Addressing to be enabled between the STS, client and service. More specifically, the client and STS bootstrap traffic have the timestamp, the WS-Addressing header elements, and the body signed. This scenario also has the Signature and the body of the SOAP message encrypted. The application messages between the client and Web service also have the timestamp, the WS-Addressing header elements, and the body signed, as well as the Signature and the body encrypted. The application messages also include a Signature Confirmation on the response that is signed and encrypted.

Getting startedTo run this example, you need to do the following on a Windows XP system:

1. Install WebSphere Application Server V8.

2. Download and install the WebSphere JAX-WS Web service samples.

3. Download and uncompress Client_and_Keys.zip. The Client_and_Keys folder contains the following folders: WCFClient, and mySysKeys.

WCFClient contains: • WSWindowsClient.cs. – The C# code for the client. This code will be

used in Part 3.

mySysKeys.zip contains:• sender.jks – keystore containing client credentials • receiver.jks – keystore containing service credentials• alice-key – Alice’s public key• alice-cert – Alice’s certificate• bob-key – Bob’s public key• bob-cert – Bob’s certificate• myca – certificate authority

Sample keys and certificatesFor this example, the following private keys and public certificates are used for the bootstrap request:

Client Consumer (keystore: C:\install\PS\mySysKeys\sender.jks / sampleapp)

Trust Service (keystore: C:\install\PS\mySysKeys\receiver.jks / sampleapp)

Request Outbound

Operation Alias DN Operation Alias DN

Signing aliceCN=alice, OU=myou,

O=myco Request Inbound

Signature Verification myca

CN=myca, OU=sec, O=ca3

Encryption bobCN=bob,

OU=myou, O=myco

Decryption bobCN=bob,

OU=myou, O=myco

Response Inbound

Operation Alias DN

Response Outbound

Operation Alias DN

Signature Verification myca

CN=myca, OU=sec, O=ca3

Signing bobCN=bob,

OU=myou, O=myco

Decryption aliceCN=alice, OU=myou,

O=mycoEncryption alice

CN=alice, OU=myou,

O=myco

The following table shows the configuration mapping for the client consumer bootstrap request:

Operation Alias DN Protection Tokens

Request Outbound

Signing aliceCN=alice, OU=myou,

O=mycogen_signx509token

Encryption bobCN=bob,

OU=myou, O=myco

gen_encx509token

Response Inbound

Signature Verification myca CN=myca,

OU=sec, O=ca3 con_signx509token

Decryption aliceCN=alice, OU=myou,

O=mycocon_encx509token

The following table shows the configuration mapping for the trust service bootstrap request:

Operation Alias DN Protection Tokens

Request Inbound

Signature Verification myca CN=myca,

OU=sec, O=ca3 con_signx509token

Decryption bobCN=bob,

OU=myou, O=myco

con_encx509token

Response Outbound

Signing bobCN=bob,

OU=myou, O=myco

gen_signx509token

Encryption aliceCN=alice, OU=myou,

O=mycogen_encx509token

Import certificates and custom keystores into Application ServerThis example uses certificates that are signed by a myca certificate authority and are managed in keystores . These sample certificates and keystores are for testing purposes only; do not use these keystores in a production environment. To import the certificates and keystores into Application Server, do the following:

1. Create the directory: C:\install\PS\mySysKeys\

2. Unzip mySysKeys.zip to a temporary directory.

3. Copy sender.jks and receiver.jks to C:\install\PS\mySysKeys\

C:\install\PS \mySysKeys\sender.jks o Keystore format is JKSo Keystore password = sampleappo Personal certificate alias name = alice, keypassword = sampleapp, certificate

authority = myca

o Public certificate alias name = bob, certificate authority = myca

C:\install\PS \mySysKeys\receiver.jks o Keystore format is JKSo Keystore password = sampleappo Personal certificate alias name = bob, keypassword = sampleapp, certificate

authority = myca o Public certificate alias name = alice, certificate authority = myca

Create interoperable policy sets and general bindingsFirst we’ll create the custom policy sets and general provider and client policy set bindings to be able to interoperate with WCF 4.0. We’ll then update these artifacts showing the differences between WebSphere Application Server V8 and WCF 4.0. At a high level those differences are:

1. WCF does not tolerate the WS-Addressing namespace attribute in the signed part of the headers for elements being signed. The OASIS WS-SecurityPolicy standard allows the use of this namespace attribute; it indicates that all SOAP headers whose namespace matches the namespace attribute are to be protected. Instead, WCF only supports the local-name attribute and not the namespace attribute for this scenario.

2. WCF only supports the optional policy assertion <sp:OnlySignEntireHeadersAndBody>.

3. WCF uses a different key size for the derived signing key. WebSphere uses a key size of 20 bytes, and WCF uses a key size of 16 bytes.

4. WCF does not support the MustSupportRefExternalURI and RequireExternalUriReference assertions in the published WSDL. Therefore they need to be removed from the WSDL before the WCF client can be generated.

Create a custom policy set for a service consumerComplete the following steps to create a custom policy set from the shipped SecureConversation policy set.

Start the Integrated Solution Console (ISC) by doing one of the following:• From the Start menu, click Start => Programs => IBM WebSphere =>

Application Server V8.0 => Profiles => AppSvr01 => Administrative Console.

• Point your browser to http://<hostname>:9060/ibm/console. Depending on your installation of the AppSrvxx profile, the console port could be different.

• Enter your Application Server administrative user ID and, if required, your password, and click Log in, as shown in Figure 1.

Figure 1. Log in to administrate console

1. Select Services in the left navigation bar.2. Expand the Policy sets and select Application policy sets.3. In the Application policy sets dialog, click Import from the collection table, and

select From Default Repository from the drop-down menu, as shown in Figure 2.

Figure 2. Import policy set

1

2 3

4. Select Import a copy and specify MyConsumerSC for the copy name, as shown in Figure 3.

Figure 3. Import MyConsumerSC

5. Ensure that the SecureConversation policy set is selected, as shown in Figure 4, and click OK to create the copy.

Figure 4. Select SecureConversation policy set

6. Save the changes.

Change WS-Addressing Headers specification in Signed Parts In this section we will now customize the client-side MyConsumerSC policy set to be interoperable with WCF. WCF does not tolerate the WS-Addressing namespace attribute to be specified in the signed part for elements being signed. Instead, WCF makes use of the local-name attribute. The WS-SecurityPolicy standard allows the use of the namespace attribute and by default the WebSphere policies are configured this way. To interoperate with WCF, need to modify the WebSphere policies to use the local-name attribute instead of the namespace attribute.

Below is the default namespace attribute:

<sp:SignedParts> <sp:Body /> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" /> </sp:SignedParts>

WCF only accepts the <sp:Header> with the local name specified. This means we have to change the WebSphere policy to the following for both the request and response:

<sp:SignedParts> <sp:Body /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" Name="From" /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" Name="MessageID" /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" Name="ReplyTo" /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" Name="FaultTo" /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" Name="Action" /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" Name="To" /> <sp:Header Namespace="http://www.w3.org/2005/08/addressing" Name="RelatesTo" /> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" Name="From" /> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" Name="MessageID" /> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" Name="ReplyTo" /> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" Name="FaultTo" />

<sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" Name="Action" /> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" Name="To" /> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" Name="RelatesTo" /> </sp:SignedParts>

1. In the Application policy sets dialog, click MyConsumerSC, as shown in Figure 5. to view the policy set details page.

Figure 5. Select MyConsumerSC

2. In the MyConsumerSC policy set detail page, click WS-Security to open the Web services security details page, as shown in Figure 6.

Figure 6. Select WS-Security

3. On the Web services security details page, select Main policy to open the details of the content of the main policy (which is used by the application messages), as shown in Figure 7.

Figure 7. Select Main policy

4. Select Request message part protection, as shown in Figure 8, to open the details of the protection policy for the request message, which defines what is to be signed or encrypted.

Figure 8. Select Request message part protection

5. Select the app_signparts from the list in the Integrity protection section, as shown in Figure 9, and click Edit to open the details of the signed parts.

Figure 9. Edit app_signparts

6. Select both the http://schemas.xmlsoap.org/ws/2004/08/addressing and http://www.w3.org/2005/08/addressing QName headers, and click Remove, then Apply, as shown in Figure 10.

1 2

Figure 10. Remove QNames

1

2

3

7. Click Add in the Elements in part collection table, and select QName from the menu, as shown in Figure 11.

Figure 11. Add QName

1

2

8. Specify http://www.w3.org/2005/08/addressing,From as the QName value, as shown in Figure 12. (Note that there is a comma (,) between http://www.w3.org/2005/08/addressing and From.) Click Apply.

Figure 12. Specify QName value

1

29. Repeat the process to add the QNames for the following:

• http://www.w3.org/2005/08/addressing,MessageID • http://www.w3.org/2005/08/addressing,ReplyTo • http://www.w3.org/2005/08/addressing,FaultTo • http://www.w3.org/2005/08/addressing,Action • http://www.w3.org/2005/08/addressing,To • http://www.w3.org/2005/08/addressing,RelatesTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,From • http://schemas.xmlsoap.org/ws/2004/08/addressing,MessageID • http://schemas.xmlsoap.org/ws/2004/08/addressing,ReplyTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,FaultTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,Action • http://schemas.xmlsoap.org/ws/2004/08/addressing,To • http://schemas.xmlsoap.org/ws/2004/08/addressing,RelatesTo

10. Save the changes.

11. Repeat the same changes for the Response message part protection. Add the following:• http://www.w3.org/2005/08/addressing,From• http://www.w3.org/2005/08/addressing,MessageID • http://www.w3.org/2005/08/addressing,ReplyTo • http://www.w3.org/2005/08/addressing,FaultTo • http://www.w3.org/2005/08/addressing,Action • http://www.w3.org/2005/08/addressing,To • http://www.w3.org/2005/08/addressing,RelatesTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,From • http://schemas.xmlsoap.org/ws/2004/08/addressing,MessageID • http://schemas.xmlsoap.org/ws/2004/08/addressing,ReplyTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,FaultTo

• http://schemas.xmlsoap.org/ws/2004/08/addressing,Action • http://schemas.xmlsoap.org/ws/2004/08/addressing,To • http://schemas.xmlsoap.org/ws/2004/08/addressing,RelatesTo

12. Repeat the same changes for bootstrap_signparts part in Secure Conversation bootstrap policy for:

• Request message part protection• Response message part protection

13. Add the following:• http://www.w3.org/2005/08/addressing,From• http://www.w3.org/2005/08/addressing,MessageID • http://www.w3.org/2005/08/addressing,ReplyTo • http://www.w3.org/2005/08/addressing,FaultTo • http://www.w3.org/2005/08/addressing,Action • http://www.w3.org/2005/08/addressing,To • http://www.w3.org/2005/08/addressing,RelatesTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,From • http://schemas.xmlsoap.org/ws/2004/08/addressing,MessageID • http://schemas.xmlsoap.org/ws/2004/08/addressing,ReplyTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,FaultTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,Action • http://schemas.xmlsoap.org/ws/2004/08/addressing,To • http://schemas.xmlsoap.org/ws/2004/08/addressing,RelatesTo

Create a service provider custom policy set Complete the following steps to create a service provider custom policy based on a copy of the MyConsumerSC policy set.

1. Select Services => Policy sets => Application policy sets.2. In the Application policy sets dialog, check MyConsumerSC and click Copy,

as shown in Figure 13.

Figure 13. Copy MyConsumerSC

3. Specify MyProviderSC as the name of copy, as shown in Figure 14.

Figure 14. Specify copy name

4. Save the changes.

1

23

3

Remove the bootstrap policyThe bootstrap policy is not being used by the service provider and can be removed. The security policy for the trust request to exchange the share secrets between the consumer and provider is configured in the Trust service attachments.

1. Select Services => Policy sets => Application policy sets in the left navigation bar.

2. In the Application policy sets dialog , select MyProviderSC.3. Select WS-Security.4. In the WS-Security dialog, shown in Figure 15, click Remove bootstrap policy

and save the changes.

Figure 15. Remove bootstrap policy

Create a custom policy set for the trust serviceThe same WS-Addressing specification changes are needed for the trust service policy set. The trust service policy set processes the WS-Trust RequestSecurityToken (RST)) request and RequestSecurityTokenResponseCollection (RSTRC) response for the bootstrap phase to establish the secure conversation.

First, we need to create a custom system policy set based on the shipped system policy set for trust. To do this, complete the following steps:

1. As shown in Figure 16, select Services => Policy sets => System policy sets in the left navigation bar.

2. Check TrustServiceSecurityDefault and click Copy to create a custom policy set that is a copy of the TrustServiceSecurityDefault default policy set for trust.

Figure 16. Copy TrustServiceSecurityDefault policy set

1

2

3

3. In the System policy sets dialog, shown in Figure 17, specify MyTrustPS as the name, and check Attach this policy set in place of the original for all attached applications, services, endpoints, and operations. All current policy set attachments of TrustServiceSystemDefault will be replaced with MyTrustPS after the copy. Select Restore default bindings to replace the bindings of TrustServiceSystemDefault policy set attachments with the trust default after the copy. Then click OK.

Figure 17. Specify system policy set options

1

22

4. Repeat the steps in Change WS-Addressing Headers specification in Signed Parts to change the specification of the WS-Addressing headers for the signed part in the Main policy for:• Request message part protection• Response message part protectionin the MyTrustPS policy set.

Add the following:• http://www.w3.org/2005/08/addressing,From• http://www.w3.org/2005/08/addressing,MessageID • http://www.w3.org/2005/08/addressing,ReplyTo • http://www.w3.org/2005/08/addressing,FaultTo • http://www.w3.org/2005/08/addressing,Action • http://www.w3.org/2005/08/addressing,To • http://www.w3.org/2005/08/addressing,RelatesTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,From • http://schemas.xmlsoap.org/ws/2004/08/addressing,MessageID • http://schemas.xmlsoap.org/ws/2004/08/addressing,ReplyTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,FaultTo • http://schemas.xmlsoap.org/ws/2004/08/addressing,Action • http://schemas.xmlsoap.org/ws/2004/08/addressing,To • http://schemas.xmlsoap.org/ws/2004/08/addressing,RelatesTo

Create a new general provider policy set binding for a service provider

Next we need to create a general provider policy set binding using the keys and certificates we created. Complete the following steps to create a new general provider policy set bindings based on the shipped Provider sample.

1. Select Services => Policy sets => General provider policy set bindings in the left navigation bar.

2. Check Provider sample and click Copy, as shown in Figure 18.

Figure 18. Copy Provider sample

1

2

3

3. Specify MyProviderGeneralBindings as the name and click OK.

Figure 19. Specify name for new general provider policy set binding

1

2

4. Click the MyProviderGeneralBindings link in the General provider policy set bindings collection table.

Figure 20. Select MyProviderGeneralBindings

5. Click the WS-Security link to open the bindings details for Web service security, as shown in Figure 21.

Figure 21. Click WS-Security

6. Click Authentication and protection, as shown in Figure 22, to open the detail page for:

• Protection tokens (tokens used for signing and encryption)• Authentication tokens (tokens used for authentication)• Signing information and encryption information for both request and response

messages

Figure 22. Message security policy bindings

7. The current configuration uses the default sample private keys and public certificates for integrity (digital signature) and confidentiality (encryption) protection. In the following steps, we’ll change the default sample private keys and public certificates to the ones that we created for this sample. See Sample Keys and Certificate Used in this Lab for details.

Figure 23. Authentication and protection tokens

8. To configure the trust store for the request inbound signature verification, check con-signx509token and click New token, as shown in Figure 23 and complete the following steps:

a. Click Callback handler

Figure 24. Select callback handler for con-signx509token

b. In our example, the certificate is signed by myca, and there aren’t any intermediary certificates. Therefore, we don’t need to have a certificate store. Select (none) from the Certificate store list.

Figure 25. Specify that no certificate store is needed

c. Now we need to create a new trust store (trust anchor store) for the trust service provider. The trust store contains Certificate Authorities (CAs) or

signer certificates that the trust service provider trusts, so we need to be careful that the trust store only contains the appropriate CAs or signer certificates. Click New beside Trusted anchor store to create a new trust store.

Figure 26. Click New to create new trust store

d. In the Trust Anchor dialog, shown in Figure 27, do the following:• Specify MYCATrustStore as the name.• Click External keystore.• Specify C:/install/PS/mySysKeys/receiver.jks as the full path to

the keystore file.• Ensure JKS is selected for the type.• Specify sampleapp as the password.• Click OK.

Figure 27. Specify trust anchor settings

1

2345

e. Select MYCATrustStore for the Trust anchor store and click OK.

Figure 28. Select MYCATrustStore

f. Save the changes.9. Now we need to configure the private key for the request inbound decryption. To do

this, click con-encx509token and click New token, as shown in Figure 23, and complete the following steps:

a. Click handler on the con-encx509token properties dialog.b. Select Custom keystore configuration under Keystore to open the key

store configuration dialog.

Figure 29. Select custom keystore

c. In the keystore configuration dialog, do the following:• Specify C:/install/PS/mySysKeys/receiver.jks as the Full path

to the keystore file.• Ensure that JKS is selected.• Specify sampleapp as the password.• Specify CN=bob, OU=myou, O=myco for the name.• Specify bob as the alias.• Specify sampleapp as the password.• Click OK.

Figure 30. Specify private keystore properties

1

2

3

4

5

6

d. Save the changes.10. Next, we need to configure the private key for response outbound signing. To do this,

click gen-signx509token and click New token, as shown in Figure 23, and complete the following steps:

a. Click Callback handler.b. Select Custom keystore under Keystore.c. In the keystore configuration dialog, do the following:

• Specify C:/install/PS/mySysKeys/receiver.jks as the full path to the keystore file.

• Ensure that JKS is selected.• Specify sampleapp as the password.• Specify CN=bob, OU=myou, O=myco for the name.• Specify bob as the alias.• Specify sampleapp as the password.• Click OK.

d. Save the changes.11. To configure the public key for response outbound encryption, click

gen_encx509token and click New token, as shown in Figure 23, and complete the following steps:

a. Click Callback handler.b. Select Custom keystore under Keystore.

c. In the keystore configuration dialog, do the following:• Specify C:/install/PS/mySysKeys/receiver.jks as the full path to

the keystore file.• Ensure that JKS is selected.• Specify sampleapp as the password.• Specify CN=alice, OU=myou, O=myco for the name.• Specify alice as the alias.• Click OK.

d. Save the changes.

Create new general client policy set bindings for the client consumer

The next step is to create general client policy set bindings with the keys and certificates used in this example. To create new general client policy set bindings based on the shipped Client sample, do the following:

1. Select General client policy set bindings => Services => Policy sets in the left navigation bar.

2. Check Client sample and click Copy, as shown in Figure 31.

Figure 31. Create new client policy set bindings from Client sample

1

2

3

3. Specify MyConsumerGeneralBindings as the name, click OK, and then click Save to save the changes as shown in Figure 32.

Figure 32. Specify name for new client policy set binding

1

2

3. Click the MyConsumerGeneralBindings link in the General client policy set bindings collection, as shown in Figure 33.

Figure 33. Select MyConsumerGeneralBindings

4. Click the WS-Security link to open the bindings details for Web service security.

5. Click Authentication and protection, as shown in Figure 34, to open the details page for:

• Protection tokens (tokens used for signing and encryption)• Authentication tokens (tokens used for authentication)• Signing Information and Encryption Information for both request and

response messages

Figure 34. Select Authentication and protection

6. The current configuration uses the default sample private keys and public certificates for integrity (digital signature) and confidentiality (encryption) protection. In the following steps, we’ll change the default sample private keys and public certificates to the ones created for this example. See Sample Keys and Certificates for details.

Figure 35. Authentication and protection tokens

7. To configure the private key for request outbound signing, click gen-signx509token and click New token, as shown in Figure 35, and complete the following steps:

a. Click Callback handler.b. Select Custom keystore under Keystore.c. In the keystore configuration dialog, do the following:

• Specify C:/install/PS/mySysKeys/sender.jks as the full path to the keystore file.

• Ensure that JKS is selected.• Specify sampleapp as the password.• Specify CN=alice, OU=myou, O=myco for the name.• Specify alice as the alias.• Specify sampleapp as the password.• Click OK.

d. Save the changes.8. To configure the public key for request outbound encryption, click gen-

encx509token and click New token, as shown in Figure 35, and complete the following steps:

a. Click Callback handler.b. Select Custom keystore under Keystore.c. In the keystore configuration dialog, do the following:

• Specify C:/install/PS/mySysKeys/sender.jks as the full path to the keystore file.

• Ensure that JKS is selected.• Specify sampleapp as the password.• Specify CN=bob, OU=myou, O=myco for the name.• Specify bob as the alias.• Click OK.

d. Save the changes.9. To configure the trust store for response inbound signature verification, click con-

signx509token and click New token, as shown in Figure 35, and complete the following steps:

a. Click Callback handler.b. In this example, the certificate is signed by myca, and there aren’t any

intermediary certificates. Therefore, we don’t need to have a certificate store. Select (none) from the Certificate store list, as shown in Figure 36.

Figure 36. Specify (none) for certificate store

10. Now we’ll create a new trust store (trust anchor store) for the client consumer’s response signature validation. Click New beside Trusted anchor store, as shown in Figure 37.

Figure 37. Create new trust store for response signature validation

a. In the Trust Anchor dialog, shown in Figure 38, do the following:• Specify ClientConsumerMYCATrustStore as the name.• Click External keystore.• Specify C:/install/PS/mySysKeys/sender.jks as the full path to

the keystore file.• Ensure JKS is selected for the type.• Specify sampleapp as the password.• Click OK.

Figure 38. Specify trust anchor properties

1

23

4

5

b. Select ClientConsumerMYCATrustStore in the Trusted anchor store list, and click OK, as shown in Figure 39.

Figure 39. Select trusted anchor store

c. Save the changes.11. To configure the private key for response inbound decryption, click click con-

encx509token and click New token, as shown in Figure 35, and complete the following steps:

a. Click Callback handler.b. Select Custom keystore under Keystore.c. In the keystore configuration dialog, do the following:

• Specify C:/install/PS/mySysKeys/sender.jks as the full path to the keystore file.

• Ensure that JKS is selected.• Specify sampleapp as the password.• Specify CN=alice, OU=myou, O=myco for the name.• Specify alice as the alias.• Specify sampleapp as the password.• Click OK.

d. Save the changes.

Configure the EchoService consumer, provider and trust services

Install the JaxWSServicesSamplesTo test the policy sets and bindings we just created you must first install the JAX-WS Web Services samples. Point your web browser at http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.samples.doc/info/ae/ae/sample_jax_ws.html and follow the instructions to download and install the samples.

Attach MyProviderSC and MyProviderGeneralBindings to EchoService provider service

Next we need to attach the policy sets and general bindings to the EchoService in JaxWSServicesSamples as follows:

1. MyProviderSC policy set and MyProviderGeneralBindings general provider policy set bindings to the EchoService provider service.

2. MyConsumerSC policy set and MyConsumerGeneralBindings general client policy set bindings to EchoService consumer client.

3. MyTrustPS policy set and MyProviderGeneralBindings general provider policy set bindings to Issue Token and Renew Token of the Trust service attachments.

Step-by-step1. Select Services => Service providers in the left navigation to list all the JAX-WS

Web service providers installed, and click EchoService, as shown in Figure 40.

Figure 40. Installed JAX-WS service providers

2. In the Policy Set Attachments dialog, shown in Figure 41, do the following:

• Check EchoService.• Click Attach Policy Set and select MyProviderSC from the menu.• Check EchoService again.• Click Assign Binding and select MyProviderGeneralBindings from the

menu.

Figure 41. Policy set attachments

1

2 4

3

The Policy Set Attachments collection table should now look like Figure 42:

Figure 42.Configured EchoService policy set attachments for provider

3. Save the changes.

Attach MyConsumerSC and MyConsumerGeneralBindings to EchoService consumer client

1. Select Services => Service clients in the left navigation to list all the JAX-WS Web service clients (consumers) installed, as shown in Figure 43, and click EchoService.

Figure 43. Installed JAX-WS clients

2. In the Policy Set Attachments dialog, do the following:

• Check EchoService.• Click Attach Policy Set and select MyConsumerSC from the menu.• Check EchoService again.• Click Assign Binding and select MyConsumerGeneralBindings from the

menu.

The Policy Set Attachments collection table should look like Figure 44.

Figure 44. Configured EchoService policy set attachments for consumer

3. Save the change.

Attach MyProviderGeneralBindings to Issue Token and Renew Token of the trust service attachments

1. Select Services => Trust service => Trust service attachments in the left navigation to list all trust service attachments, as shown in Figure 45.

Figure 45. Trust service attachments

12

4

3

2. In the Trust service attachments dialog, do the following:• Check Issue Token and Renew Token.• Click Assign Binding and select MyProviderGeneralBindings from the

menu.

The Trust service attachments collection table should look like Figure 46.

Figure 46. Configured EchoService trust service attachments

3. Save the change. 4. Click Update Runtime to refresh the trust service attachments. The trust service

attachments are cached, and this will update the runtime cache with the latest changes.

5. Stop and restart Application Server.

Get the WSDLThe publishing of WS-SecurityPolicy assertions in the WSDL is disabled by default. You can verify the WSDL from the service provider by issuing an HTTP GET request from http://localhost:9080/WSSampleSei/EchoService?wsdl.

Figure 47. WSDL<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions name="EchoService" targetNamespace="http://com/ibm/was/wssample/sei/echo/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://com/ibm/was/wssample/sei/echo/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">

<wsdl:types> <xsd:schema targetNamespace="http://com/ibm/was/wssample/sei/echo/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="echoStringResponse"><xsd:complexType>

<xsd:sequence><xsd:element name="echoResponse" type="xsd:string"/>

</xsd:sequence></xsd:complexType>

</xsd:element><xsd:element name="echoStringInput">

<xsd:complexType><xsd:sequence>

<xsd:element name="echoInput" type="xsd:string"/></xsd:sequence>

</xsd:complexType></xsd:element>

</xsd:schema> </wsdl:types> <wsdl:message name="echoOperationRequest"> <wsdl:part name="parameter" element="tns:echoStringInput"> </wsdl:part> </wsdl:message> <wsdl:message name="echoOperationResponse"> <wsdl:part name="parameter" element="tns:echoStringResponse"> </wsdl:part> </wsdl:message> <wsdl:portType name="EchoServicePortType"> <wsdl:operation name="echoOperation"> <wsdl:input message="tns:echoOperationRequest"> </wsdl:input> <wsdl:output message="tns:echoOperationResponse"> </wsdl:output> </wsdl:operation> </wsdl:portType> <wsdl:binding name="EchoSOAP" type="tns:EchoServicePortType">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="echoOperation"> <soap:operation soapAction="echoOperation" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="EchoService"> <wsdl:port name="EchoServicePort" binding="tns:EchoSOAP"> <soap:address location="http://localhost:9080/WSSampleSei/EchoService"/> </wsdl:port> </wsdl:service></wsdl:definitions>

Test the EchoServiceNow that you have finished configuring the Application Server client and service, you can test to ensure that WebSphere-to-WebSphere Secure Conversation flows are operational. We’ll use the SEI Samples demo to test the EchoService client to EchoService service to validate our security configuration.

1. To test the EchoService using the SEI samples demo UI, point your browser to http://localhost:9080/wssamplessei/demo.

2. To validate that the EchoService client and EchoService service are properly configured, in the Message options dialog, shown in Figure 48, do the following:• Select Synchronous Echo for Message Type.• Enter some text (such as test) in the Message String field.• For the Service URI, specify the hostname and port number of the service

endpoint (for example: http://localhost:9080).• Click Send Message.

Figure 48. Specify message options

The response box shows the connection status, the message request, and the message response. Note that the message response is JAX-WS==>>test. The service prepends JAX-WS==>> to the Message Request string test. If you see an exception for message response, check the System.out log and review the security custom binding configurations for both the client and the service. Resolve any problems before you continue.

SummaryIn this article, we implemented a scenario that leverages WS-SecureConversation to secure SOAP messages exchanged between the WebSphere Application Server V8 Web services client and service. You learned how to configure the Application V8 Security Trust Service and how to create a WS-SC based policy set and custom binding using the policy-based administration features for JAX-WS Web services deployed on Application Server.

ResourcesSpecificationsWeb Services Security: SOAP Message Security 1.0 WS-Security (2004)Web Services Security: SOAP Message Security 1.1Web Services Secure Conversation

WebSphere Application Server V8 Information CenterWebSphere Application Server V8 Information Center : Introduction to Web Services

Feature Pack for Web Services and developerWorks Achieving Web services interoperability between the WebSphere Web Services Feature Pack and Windows Communication Foundation, Part 1 (developerWorks 2007): Part 1 of this series describes how to use the WebSphere Application Server Version 6.1 Feature Pack for Web Services Service Endpoint Interface samples to demonstrate interoperability with Microsoft Windows Communication Foundation. It provides step-by-step instructions on how to achieve basic Web services interoperability for SOAP 1.1, SOAP 1.2, and WS-Addressing.

Achieving Web services interoperability between the WebSphere Web Services Feature Pack and Windows Communication Foundation, Part 2: Configure and test WS-Security(developerWorks 2007): Part 2 of this series focuses on how to configure a custom WebSphere WS-Security policy set and binding, how to configure WS-Security in a WCF customBinding, and how to test WS-Security interoperability between WebSphere and WCF.

Achieving Web services interoperability between the WebSphere Web Services Feature Pack and Windows Communication Foundation, Part 3: Configure and test WS-Secure conversation(developerWorks 2008): Part 3 of this series focuses on how to configure a custom WebSphere WS-SecureConversation policy set and binding, how to configure WS-SecureConversation in a WCF customBinding, and how to test WS-SecureConversation interoperability between WebSphere and WCF.

Windows Communication FoundationWeb Services Protocols Interoperability Guide: This topic provides a list of Web Services Protocols implemented by WCF.

Web Services Protocols Supported by System-Provided Interoperability Bindings: This topic lists specifications that are supported by system-provided interoperable bindings.

About the authors

Tom Link works as an advisory software engineer on the IBM WebSphere web services interoperability team. Tom is an active member of the OASIS community, an open industry organization chartered to promote Web interoperability. Prior to joining the web services group, Tom developed the PalmOS user interface for the WebSphere Everyplace product. Since joining IBM in 1977, Tom has worked on many IBM, WebSphere and Lotus software products.

Henry Chung is an architect and lead developer of Web services security on the WebSphere platform. Henry has been in middleware development for over five years and has developed many security features for the WebSphere platform. Henry’s current focus is leading the development of the latest WebSphere Web services security specifications. He also helps customers and other IBM teams apply Web services security solutions. His primary goal is to enable WebSphere Web services security support to meet real-world needs.

Charles Le Vay is a senior software architect and WebSphere Evangelist. Prior to this position, Charles was interoperability architect for WebSphere Application Server. He also specialized in mobile application development, wireless technology, and extending enterprise applications securely to mobile devices. Before joining IBM, Charles developed advanced submarine sonar systems for the Navy and specialized in signal processing and underwater acoustics. He is a graduate of Duke University with a degree in physics.

Salim Zeitouni is an advisory software engineer on the IBM WebSphere Commerce team. Prior to joining the Commerce group, Salim was part of the WebServices Interoperability team, and was also a team lead on several IBM WebSphere products that provide integrated client-server environment and application development tools to extend business applications and data to mobile users. Since joining IBM in 1996, Salim has worked on several of the WebSphere, Tivoli, and Lotus software products.