This article and the attached sample model included in the Download section below describe how to call a web service from a WebSphere® Portlet Factory model that requires passing a Web Service Security UsernameToken for the service to authenticate the caller.
Here are some of the techniques illustrated in this sample:
- Calling a Web Service from a WebSphere Portlet Factory model
- Adding a Web Service Security (WSS) UsernameToken SOAP header to the web service call
The OASIS Web Service Security specifications (WSS) at http://www.oasis-open.org/home/index.php
describe how to secure web service calls, and define a core set of extensions to web service protocols, and then extensions for specific types of authentication data, signatures and encryption.
This article and sample model builds on the following developerWorks article which describes a web service running on WebSphere Application Server that requires use of the WSS UsernameToken authentication mechanism, where a SOAP header conforming to the WSS UsernameToken Profile must be sent in the SOAP envelope, including a username and text based password.
As shown and discussed in that developerWorks article, once you have the environment set up (WebSphere, security ...) and the secured web service deployed, the web service requires a SOAP envelope similar to the following (note, the WSS soap header):
Note that, depending on the version of the OASIS Web Service Security specifications in use by the web service, you may need different namespace URIs (for example, 1.1 versus 1.0) specified in the WSS SOAP headers. The developerWorks article above describes a service that requires the 1.0 version of the WSS UsernameToken profile. So that is what this WPF sample model generates as a WSS header to be compatible with the service created in conjunction with that article.
After creating the Web Service Call for the web service that we wish to consume, we define an XML Variable with the structure that is defined by WSS UsernameToken Profile 1.0.
Then, specify this WPF Variable as a SOAP Header, in the Web Service Call builder's advanced inputs.
This sample then uses an InputForm builder, associated with the WS Security UsernameToken profile XML Variable, to populate the username and password included in that variable's XML data to be sent as the SOAP header. In an actual portlet application, you would likely want to use the WP Credential Vault to retrieve the username and password to be send with the WS UsernameToken SOAP header.
Notes on running the sample and prerequisites
Import the attached zip file into your project using the Import WebSphere Portlet Factory Archive command.
Note, the WPF sample model will only run successfully and to completion if you have deployed the web service described in the above developerWorks article, and the Service URL in the Web Service Call builder's advanced inputs is set to where you have deployed the web service described in the article.
If you have not deployed the service described in the developerWorks article, you may still download and review this sample WPF model in the Designer, and even run it to generate logging information. But the sample will fail with a connection error when it tries to call the nonexistent web service.
The Web Service Call builder in the sample model has Logging set to All, so that the generated SOAP envelope will be saved to your deployed web application's WEB-INF/logs folder in debugTracing.txt. After reviewing the builders and builder inputs in the model, try running it. Specify a username and password on the login page, and then a temperature (zero will do fine) on the conversion page. Then submit the temperature value to call the web service. Whether the service is available or not, you should then be able to inspect the SOAP Request envelope generated by the web service call in WEB-INF/logs/debugTracing.txt of your deployed web application.