This document is a member of the Bare Series of WAS topics distributed in both stand-alone and in collection form. The latest renderings and source are available on GitHub at http://pglezen.github.io/was-config.
Table of Contents
If you lock down your service provider too tightly, not even your testers can invoke it with SOAP-UI. This section explains how to configure SOAP-UI to invoke a web service that only accepts payloads with timestamps signed by certain parties. Of course, one of those parties needs to be the tester.
These steps describe how to create a tester key store for use in signing requests to the provider. There is no requirement that this be done on WAS. One could use the JDK keytool if desired. The WAS admin console is just easier. Since there is no requirement to manage this keystore as part of a cell, it is not created within the cell configuration and synchronized across nodes.
The public certifiate associated with the tester's key is exported so that it can be included within the provider's trust store.
Key store used by testers, not by WAS.
Acme Tester 1.
.cerextension. This will be the location from which it will be imported into the service provider's trust store.
tester1alias used for creating the certificate is a good choice.
The root entry is the WAS cell root that is created automatically for each new key store. It does not play a role here. The ccconsumer certificate belongs to the consumer application and tester1 is the tester certificate that was just imported. It will allow the service provider to accept requests signed by this tester.
The next section will explain how to configure the tester's SOAP-UI installation to sign requests with the new key.
In SOAP-UI we start with a SOAP project that invokes a service provider. The SOAP-UI has no WS-Security configured. They keystore and its passwords from the previous step are readily available.
This completes the configuration of the key store within SOAP-UI. The key store panel should look like Figure 4.
This section continues from configuration panel of the previous section.
120(seconds) to avoid any problems with clock skew between the test machine and the service provider. Uncheck the box for Millisecond precision.
This is the easy part. Start with any sample request payload (without the WS-Security header). Right-click in the request payload editor and select Figure 8.→ as shown in
This will slap the WS-Security header right into the payload.
Do not alter the WS-Security header after generating the timestamp and signature (such as reformating it). In most cases this will invalidate the signature.
After generating the timestamp and signature, be sure to invoke the CC provider within 120 seconds (before the timestamp expires). After the timestamp expires, simply generate a new WS-Security header using the same menu option shown in Figure 8. It will replace the existing WS-Security header with a new one automatically. There is no need to manually delete the old one. If you wish to simply remove the old WS-Security header without adding a new one, right-click into the request editor and select → .
Here are some troubleshooting tips for when things go wrong.
Check the logs on both sides. For WAS, there is always the
SystemOut.log file. For SOAP-UI there
the SoapUI log and error log
tabs at the bottom of the window as shown in
As mentioned above, formatting the request payload corrupts the signature. But if you've already invoked the request (for better or worse) and you wish to view the security header, go ahead and reformat using by right-clicking in the request panel and selecting. This will allow you to see the header elements more clearly for troubleshooting.