WS-SecureConversation interoperability between WebSphere Application Server V8 and Windows Communication

WS-SecureConversation interoperability between WebSphere
Application Server V8 and Windows Communication
Foundation using dynamic policy configuration, Part 2:
Configure and test the WebSphere web services client
Thomas Link
Advisory Software Engineer
Web Services Interoperability Development
IBM, Research Triangle Park, NC
Hyen-Vui (Henry) Chung
Senior Software Engineer
Web Services Architect
Amazon
Charles Le Vay
Senior Software Engineer
WebSphere Technical Evangelist - Emerging Technology
IBM, Research Triangle Park, NC
Salim Zeitouni
Advisory Software Engineer
WebSphere Commerce Development Software Developer
IBM, Research Triangle Park, NC
November, 2011
© Copyright International Business Machines Corporation 2011. All rights reserved.
This series of articles describes how to use the IBM WebSphere Application Server Version
8 Endpoint Interface samples to demonstrate interoperability with Microsoft™ Windows™
Communication Foundation. It provides step-by-step configurations to show you what you need
to do for SOAP message security interoperability using WS-SecureConversation.
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.
Introduction........................................................................................................................................
Before you begin................................................................................................................................
Enable policy sharing using dynamic policy.....................................................................................
Enable the service consumer for dynamic policy......................................................................
Test WebSphere Application Server to WebSphere Application Server conversation using
dynamic policy...................................................................................................................................
Obtain the WSDL..........................................................................................................................
Test the EchoService client and service........................................................................................
Summary............................................................................................................................................
Resources...........................................................................................................................................
Specifications.............................................................................................................................
WebSphere Application Server Information Center..................................................................
Feature Pack for Web Services & developerWorks..................................................................
Windows Communication Foundation......................................................................................
About the authors...........................................................................................................................
Introduction
WebSphere Application Server Version 8 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 WSAddressing (WS-A), WS-Security, WS-Reliable Messaging (WS-RM), and WSSecureConversation (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 and binding.
2. Dynamically configure a WebSphere Application Server web services client using the WSSecurity policy assertions emitted from WebSphere and test it with a WebSphere
Application Server service provider.
3. Dynamically configure a WCF client using the WS-Security policy assertions emitted from
WebSphere and test it with a WebSphere Application Server service provider.
This article focuses on dynamically configuring a WebSphere Application Server web services
client using the WS-Security policy assertions emitted from WebSphere and testing it with a the
WebSphere Application Server service provider.
Before you begin
You must successfully complete and test the WS-SecureConversation policy set and bindings
described in Part 1 before beginning the steps in this article.
Enable policy sharing using dynamic policy
In this section, you will enable the service provider to emit policy assertions in the WSDL.
Start the Integrated Solution Console by doing one of the following:
1. Start the Integrated Solution Console by doing one of the following
• From the Start menu, select Start => Programs => IBM WebSphere => Application
Server V8.0 => Profiles => AppSvr01 => Administrative Console.
• In a browser, go to http://<hostname>:9060/ibm/console. Depending on your installation
of the AppSrvxx profile, the console port may be different.
2. 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 the administrative console
3. Select Services => Service providers in the left navigation bar to list all the JAX-WS web
service providers installed, as shown in Figure 2:
Figure 2. List web service providers
4. Click EchoService in the collection table to navigate to the detail page.
5. Click Disabled under Policy Sharing for EchoService, as shown in Figure 3.
Figure 3. Click on Disabled
6. Check Exported WSDL, as shown in Figure 4.
Figure 4. Check Exported WSDL
7. Click OK.
8. Save the changes.
Enable the service consumer for dynamic policy
In this section, you will learn how to configure the client to consume the dynamic policy
assertions emitted from the service provider.
1. Select Services => Service clients in the left navigation area to list all the JAX-WS web
service clients (consumers) installed, as shown in Figure 2 above.
2. Click EchoService in the collection table to navigate to the detail page, as shown in Figure 5.
Figure 5. EchoService detail page
3. Check the check box of the EchoService row.
4. Click Detach Client Policy Set.
5. Click None under Policies Applied, as shown in Figure 6.
6. Select Provider policy only from the list of policies to apply, as shown in Figure 7.
7. Select HTTP Get request, and Use the default request target.
8. Click OK.
9. Check the check box of the EchoService row.
10. In the Assign Binding menu, select MyConsumerGeneralBindings.
The Policy Set Attachments collection table should look like Figure 8.
9. Save the change.
10. Stop and restart the application server.
Test WebSphere Application Server to WebSphere
Application Server conversation using dynamic policy
Now that you have finished configuring the WebSphere Application server client and service to
use dynamic policy, you can test to ensure that WebSphere-to-WebSphere SecureConversation
flows are operational. You’ll use the SEI samples demo to test the WebSphere EchoService
client to WebSphere EchoService service to validate our security configuration.
Obtain the WSDL
The publishing of WS-SecurityPolicy assertions in the WSDL is currently enabled. You can
verify the WSDL from the service provider by issuing an HTTP GET request through the
browser using the URL: http://localhost:9080/WSSampleSei/EchoService?wsdl. You should now
see WS-SecurityPolicy assertions in the WSDL. Listing 1 shows the WSDL.
Listing 1. WSDL
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="EchoService"
targetNamespace="http://com/ibm/was/wssample/sei/echo/" xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
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" />
<wsp:PolicyReference URI="#33cbf62d-fcdd-4c96-8d30-0b3af1a180e1" />
<wsdl:operation name="echoOperation">
<soap:operation soapAction="echoOperation" style="document" />
<wsdl:input>
<SOAP:BODY USE="LITERAL" />
<wsp:PolicyReference URI="#921b09e1-9ac6-42d3-80ff-ee0519cd1988" />
</wsdl:input>
<WSDL:OUTPUT>
<SOAP:BODY USE="LITERAL" />
<wsp:PolicyReference URI="#ff5139d6-72c8-4a53-9ef9-8ca9533524a7" />
</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>
<WSP:POLICY WSU:ID="33CBF62D-FCDD-4C96-8D30-0B3AF1A180E1">
<wsp:ExactlyOne>
<WSP:ALL>
<ADDRESSING:ADDRESSING
XMLNS:ADDRESSING="HTTP://WWW.W3.ORG/2007/05/ADDRESSING/METADATA">
<wsp:Policy>
<WSP:EXACTLYONE>
<WSP:ALL />
</WSP:EXACTLYONE>
</WSP:POLICY>
</ADDRESSING:ADDRESSING>
</WSP:ALL>
<WSP:ALL>
<ADDRESSING:ADDRESSING
XMLNS:ADDRESSING="HTTP://WWW.W3.ORG/2007/05/ADDRESSING/METADATA">
<wsp:Policy>
<WSP:EXACTLYONE>
<WSP:ALL>
<ADDRESSING:ANONYMOUSRESPONSES />
</WSP:ALL>
</WSP:EXACTLYONE>
</WSP:POLICY>
</ADDRESSING:ADDRESSING>
</WSP:ALL>
<WSP:ALL>
<ADDRESSING:ADDRESSING
XMLNS:ADDRESSING="HTTP://WWW.W3.ORG/2007/05/ADDRESSING/METADATA">
<wsp:Policy>
<WSP:EXACTLYONE>
<WSP:ALL>
<ADDRESSING:NONANONYMOUSRESPONSES />
</WSP:ALL>
</WSP:EXACTLYONE>
</WSP:POLICY>
</ADDRESSING:ADDRESSING>
</WSP:ALL>
<WSP:ALL />
</WSP:EXACTLYONE>
<NS2:SYMMETRICBINDING
XMLNS:NS2="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702">
<wsp:Policy>
<NS2:INCLUDETIMESTAMP />
<NS2:PROTECTIONTOKEN>
<WSP:POLICY>
<NS2:SECURECONVERSATIONTOKEN
NS2:INCLUDETOKEN="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702/INCLUDETOKEN/ALWAYSTORECIPIENT">
<wsp:Policy>
<NS2:REQUIREDERIVEDKEYS />
<NS2:REQUIREEXTERNALURIREFERENCE />
<NS2:BOOTSTRAPPOLICY>
<WSP:POLICY>
<NS2:ASYMMETRICBINDING>
<WSP:POLICY>
<NS2:INITIATORTOKEN>
<WSP:POLICY>
<NS2:X509TOKEN
NS2:INCLUDETOKEN="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WSSECURITYPOLICY/200702/INCLUDETOKEN/ALWAYSTORECIPIENT">
<wsp:Policy>
<NS2:WSSX509V3TOKEN10 />
</WSP:POLICY>
</NS2:X509TOKEN>
</WSP:POLICY>
</NS2:INITIATORTOKEN>
<NS2:ALGORITHMSUITE>
<WSP:POLICY>
<NS2:BASIC128RSA15 />
</WSP:POLICY>
</NS2:ALGORITHMSUITE>
<NS2:LAYOUT>
<WSP:POLICY>
<NS2:STRICT />
</WSP:POLICY>
</NS2:LAYOUT>
<NS2:RECIPIENTTOKEN>
<WSP:POLICY>
<NS2:X509TOKEN
NS2:INCLUDETOKEN="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WSSECURITYPOLICY/200702/INCLUDETOKEN/ALWAYSTOINITIATOR">
<wsp:Policy>
<NS2:WSSX509V3TOKEN10 />
</WSP:POLICY>
</NS2:X509TOKEN>
</WSP:POLICY>
</NS2:RECIPIENTTOKEN>
<NS2:INCLUDETIMESTAMP />
<NS2:ENCRYPTSIGNATURE />
</WSP:POLICY>
</NS2:ASYMMETRICBINDING>
<NS2:WSS11>
<WSP:POLICY>
<NS2:REQUIRESIGNATURECONFIRMATION />
<NS2:MUSTSUPPORTREFKEYIDENTIFIER />
</WSP:POLICY>
</NS2:WSS11>
<NS2:SIGNEDPARTS>
<NS2:BODY />
<NS2:HEADER NAME="FROM"
Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="MessageID"
Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="To"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="RelatesTo"
Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="Action"
Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="From"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="ReplyTo"
Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="Action"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="FaultTo"
Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="MessageID"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="RelatesTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="ReplyTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="To"
Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="FaultTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
</ns2:SignedParts>
<NS2:ENCRYPTEDPARTS>
<NS2:BODY />
</NS2:ENCRYPTEDPARTS>
</WSP:POLICY>
</NS2:BOOTSTRAPPOLICY>
<NS2:MUSTNOTSENDAMEND />
</WSP:POLICY>
</NS2:SECURECONVERSATIONTOKEN>
</WSP:POLICY>
</NS2:PROTECTIONTOKEN>
<NS2:ALGORITHMSUITE>
<WSP:POLICY>
<NS2:BASIC128RSA15 />
</WSP:POLICY>
</NS2:ALGORITHMSUITE>
<NS2:LAYOUT>
<WSP:POLICY>
<NS2:STRICT />
</WSP:POLICY>
</NS2:LAYOUT>
<NS2:ENCRYPTSIGNATURE />
</WSP:POLICY>
</NS2:SYMMETRICBINDING>
<NS2:WSS11
XMLNS:NS2="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702">
<wsp:Policy>
<NS2:REQUIRESIGNATURECONFIRMATION />
<NS2:MUSTSUPPORTREFEXTERNALURI />
</WSP:POLICY>
</NS2:WSS11>
<NS2:TRUST13
XMLNS:NS2="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702">
<wsp:Policy>
<NS2:MUSTSUPPORTISSUEDTOKENS />
<NS2:REQUIRECLIENTENTROPY />
<NS2:REQUIRESERVERENTROPY />
</WSP:POLICY>
</NS2:TRUST13>
</WSP:POLICY>
<WSP:POLICY WSU:ID="921B09E1-9AC6-42D3-80FF-EE0519CD1988">
<ns2:SignedParts
XMLNS:NS2="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702">
<ns2:Body />
<NS2:HEADER NAME="RELATESTO"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="From"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="FaultTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="Action"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="ReplyTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="To"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="MessageID"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
</ns2:SignedParts>
<NS2:ENCRYPTEDPARTS
XMLNS:NS2="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702">
<ns2:Body />
</NS2:ENCRYPTEDPARTS>
</WSP:POLICY>
<WSP:POLICY WSU:ID="FF5139D6-72C8-4A53-9EF9-8CA9533524A7">
<ns2:SignedParts
XMLNS:NS2="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702">
<ns2:Body />
<NS2:HEADER NAME="FROM" NAMESPACE="HTTP://WWW.W3.ORG/2005/08/ADDRESSING"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="MessageID"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="To"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="RelatesTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="ReplyTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="FaultTo"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="From"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
<ns2:Header Name="Action"
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns="" xmlns:ns10="http://www.w3.org/2005/08/addressing" />
</ns2:SignedParts>
<NS2:ENCRYPTEDPARTS
XMLNS:NS2="HTTP://DOCS.OASIS-OPEN.ORG/WS-SX/WS-SECURITYPOLICY/200702">
<ns2:Body />
</NS2:ENCRYPTEDPARTS>
</WSP:POLICY>
</WSDL:DEFINITIONS>
Test the EchoService client and service
Start the SEI samples demo user interface by pointing your browser to
http://localhost:9080/wssamplessei/demo. To validate that the EchoService client and
EchoService service are properly configured, select Synchronous Echo for Message Type,
enter some text (such as test) in the Message String field, enter the hostname and port number
of the service endpoint (for example: http://localhost:9080), then click Send Message, as
shown in Figure 9.
Figure 9. Test the EchoService client and service
The response
box shows
the
connection
status, the
Message
Request, and
the Message
Response.
Note that the
Message
Response is
JAXWS==>>test.
The service
prepends
JAX-WS==>>
to the
Message
Request
string test.
If you see an
exception in
the Message
Response
box, check
the
System.out
log and
review the
security custom binding configurations for both the client and the service. You should resolve
these problems before you continue to the WCF configuration in Part 3.
Summary
In 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 Service provider to emit policy assertions and
how to dynamically configure a WebSphere web services client using these policy assertions.
Resources
Specifications
Web Services Security: SOAP Message Security 1.0 WS-Security (2004)
Web Services Security: SOAP Message Security 1.1
Web Services SecureConversation
WebSphere Application Server Information Center
WebSphere Application Server V8 Information Center: Introduction to web services
Feature Pack for Web Services & developerWorks
WS-SecureConversation interoperability between WebSphere Application Server V8 and
Windows Communication Foundation using dynamic policy configuration, Part 1: Configure and
test WS-Secure Conversation (developerWorks 2009): Part 1 of this series focuses on statically
configuring a custom WebSphere WS-SC policy set and binding.
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 testWS-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-SecureConversation
(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 Foundation
Web 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 currently a software development engineer at Amazon. Prior to that, Henry was
the architect on the WebSphere Web Services development team, the architect and lead
developer of Web services security on the WebSphere platform. Henry has been in middleware
development for over 10 years and has developed many security features for the WebSphere
platform.
Charles Le Vay is a senior software architect and technical evangelist on the WebSphere
Emerging Technologies team. His current focus is on promoting the advantages of elastic data
grid technology within the enterprise. Before becoming a technical evangelist, Charles was the
Web Service interoperability architect for IBM's WebSphere Application Server. He represented
IBM on the Web Service Interoperability Organization (WS-I) Reliable Secure Profile (RSP)
Working Group. As an interoperability architect, Charles focused on ensuring IBM products
meet industry standard interoperability criteria. He was responsible for identifying and detailing
best practices for Web services interoperability. Prior to this position, Charles 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. Charles is a
graduate of Duke University with a degree in physics.
Salim Zeitouni works as an Advisory Software Engineer on the IBM WebSphere Web services
interoperability team. He is an active member of the WS-I community, an open industry
organization chartered to promote Web services interoperability and currently chairs the Sample
Applications Work Group. Prior to joining the Web services team, Salim was a team lead on
several 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 WebSphere, Tivoli, and Lotus software products.