Mindreef

Version 6.2.0.0 and prior, of the Mindreef SOAPscope Server product family, does not support loading WSDL contracts from the File tab in Firefox 3. The message "Error: Unable to find contract" displays after you browse to a file and click 'Add Contract'.
 
These workarounds are available:
 
1) Use the URL tab, and put "file://" in front of the file path.
Example: file://C:\pathname\file.wsdl
 
2) Use a supported browser such as Firefox 2.0.0.x, Internet Explorer 7 or Internet Explorer 6. Firefox 2 is temporarily available here:
http://www.mozilla.com/en-US/firefox/all-older.html
 
3) Use the Mindreef Contract Upload application, available under Downloads on the Settings or My Settings page of your Mindreef SOAPscope Server product family web application.

 

The Mindreef Team 9:37am

U.S. Daylight Savings Time (DST) start and end dates change in 2007. This change is unlikely to cause any problems in Mindreef products, but you can use the following procedure to update the time zone tables in SOAPscope and SOAPscope Server. SOAPscope Server users should also update the Mindreef Collector, if it is installed as a standalone module.

1) Stop SOAPscope, SOAPscope Server, and the Collector from the green icon in the Windows System Tray.

2) Download the JDK US DST Timezone Update Tool from this link:
http://java.sun.com/javase/downloads/index.jsp

The Timezone Update Tool inserts new time zone data under a single existing image of the Sun JDK or JRE software. Run the tool against each instance of the JDK or JRE you want to update. Identification strings or properties of the JRE will not change, but you can use the tool to verify that the update was applied.

For additional information see:
http://java.sun.com/developer/technicalArticles/Intl/tzupdatertool.html

3) Extract tzupdater.jar from the downloaded zip file to the jre/bin folder of your SOAPscope, SOAPscope Server, or Mindreef Collector installation.

Example:
If you have SOAPscope installed in:
C:\Program Files\Mindreef\SOAPscope Server 5.3

Extract to: C:\Program Files\Mindreef\SOAPscope Server 5.3\jre\bin\tzupdater.jar

4) Open a command prompt in the jre\bin folder.

To do this:
a) From Windows Start menu -> Run -> cmd.exe to open up a command prompt
b) Navigate to the jre\bin directory using the "cd" command
Example:
cd "C:\Program Files\Mindreef\SOAPscope Server 5.3\jre\bin"

5) Execute the tzupdater utility with this command:
java -jar tzupdater.jar -u -v

Your output will be similar to this:

java.home: C:\Program Files\Mindreef\SOAPscope Server 5.3\jre
java.vendor: Sun Microsystems Inc.
java.version: 1.4.2_05
JRE time zone data version: tzdata2003a
Embedded time zone data version: tzdata2007a
Extracting files... done.
Renaming directories... done.
Validating the new time zone data... done.
Time zone data update is complete.

6) To check if a system has the timezone update, install tzupdater.jar in jre\bin, and execute the same command:
java -jar tzupdater.jar -u -v

Your output will be similar to this:
java.home: C:\Program Files\Mindreef\SOAPscope Server 5.3\jre
java.vendor: Sun Microsystems Inc.
java.version: 1.4.2_05
JRE time zone data version: tzdata2007a
Embedded time zone data version: tzdata2007a
You have the same version as the embedded one.

7) After applying the time zone update, you may delete tzupdater.jar.

8) If you installed a message Collector for SOAPscope Server, you should also use tzupdater.jar to update the JRE installed with the Collector.

Default location:
C:\Program Files\Mindreef\Collector 5.3\jre\bin

Client certificates are a type of X.509 certificate used when an SSL/TLS client and server must mutually authenticate. SOAPscope includes support for client certifcates when invoking an SSL-enabled Web service. Although the documentation contains instructions for configuring SOAPscope to use client certificates, we have discovered that the documented procedure is not adequate for all users. If you would like to understand why, read the next paragraph; otherwise you can skip ahead to the two alternative solutions that follow.

Client certificates differ from the more commonplace server certificates in that they contain both a private key and a certificate chain. If you display the contents of a keystore file using the "keytool -list" command, a client certificate is listed as a "keyEntry" (due to the presence of the private key), while a server certificate is listed as a "trustedCertEntry". As it turns out, the keytool utility will only import a client certificate as a "keyEntry" if the certificate is obtained as a reply to a Certificate Signing Request (CSR), and replaces the CSR in the keystore file. Since the instructions in our documention attempt to import a client certificate without going through the CSR process, the result is that a client certificate gets added as a "trustedCertEntry", and thus will not be used properly by SOAPscope. For more than you probably want to know about keytool's import command, read this.

Note on both solutions: to locate the directory referred to below as "<SOAPscope-data-directory>", use Start / Programs / Mindreef SOAPscope 4.1 / View SOAPscope Data Directory.

Solution 1 — this assumes that you have your own keystore file that contains one or more client certificates:

1. Replace the SOAPscope file client.ks with your keystore. You will have to change your file so that it uses "mrsoap" as the password for both the keystore as a whole and for the individual entries in the file, as explained in steps 5 and 6. DO NOT use this procedure if you have previously added any certificates to client.ks.
2. Stop the SOAPscope service.
3. Copy your keystore file to a new file called client.ks.
4. Use keytool -storepasswd to change the password for client.ks to "mrsoap".
5. For each entry/alias in the file, use keytool -keypasswd to change its password to "mrsoap". (Use keytool -list to get the list of entries.)
6. Go to <SOAPscope-data-directory>\ssl\ and rename client.ks as client.ks.saved.
7. Copy your file to <SOAPscope-data-directory>\ssl\.
8. Restart the SOAPscope service.

Solution 2 — this assumes that you have either your own keystore file, or a client certificate in its own file. The procedure will have you copy each entry in your keystore/certificate file into client.ks. You will need a small utility program called keymove, which can be downloaded from http://mindreef.destek.com/products/SOAPscope/4.1/keymove.jar.

1. Stop the SOAPscope service.
2. Copy your keystore/certificate file to <SOAPscope-data-directory>\ssl\.
3. Use the keymove utility to copy the entries in your keystore/certificate file into client.ks. The command line will look something like this: java -jar keymove.jar JKS YOUR_KEYSTORE_FILENAME YOUR_KEYSTORE_PASSWORD JKS client.ks mrsoap
4. Restart the SOAPscope service.

The Mindreef Team 10:01 AM

Please read the TechNote below (Using SOAPscope SSL Forwarding From a .NET Client) for background information. This note describes how to change an Axis client so that you can use it with the SOAPscope SSL Forwarding feature. As described previously, SOAPscope uses a self-signed (untrusted) certificate in this configuration, and your application needs to be able to accept the connection.

Axis makes this very easy to do; all it takes is a single line of code:

System.setProperty("axis.socketSecureFactory", "org.apache.axis.components.net.SunFakeTrustSocketFactory");

Add this line before the code that instantiates the service object.

WARNING: this code should not be used in a production environment, as it will allow your client to connect to any SSL server, trusted or not.

On the of the new features in SOAPscope 4.1 is SSL forwarding, a technique that allows you to use SOApscope to capture SOAP traffic over SSL/TLS/HTTPS, logging the messages in cleartext while still using encryption between the client and server.

In SOAPscope version 4.1 Service Pack 1, this feature is not sufficiently documented, in that we don't explain how to set to a client to work with this feature. We'll correct the documentation in the next service pack release, but in the meantime, here is what you need to know for .NET clients. We'll follow this up with another TechNote that covers Axis clients.

To use the SSL Forwarding feature, you configure SOAPscope to listen for SSL traffic on a particular port. When your client connects to that port, SOAPscope decrypts the data, logs it, re-encrypts it, and forwards the data to and from the Web service. SOAPscope uses a self-signed SSL certificate to validate the forwarding socket. However, most client applications treat a self-signed certificate as untrusted, because it has not been signed by a trusted Certificate Authority, and will refuse the connection. Therefore your client app may need to be modifed slightly to allow it to connect.

Here's how to do that in a .NET/C# client application:

1. Somewhere in your code, add the following class:
   
class OverrideCertificatePolicy : ICertificatePolicy
{
    public bool CheckValidationResult(ServicePoint srvPoint, System.Security.Cryptography.X509Certificates.X509Certificate certificate, WebRequest request, int certificateProblem)
    {
        return true;
    }
}
   
2. Somewhere in your mainline code, before you instantiate the service object, add the following line:
   
ServicePointManager.CertificatePolicy = new OverrideCertificatePolicy();

   

Here's the explanation: in Step 1, the class OverrideCertificatePolicy implements the ICertificatePolicy interface, which defines how SSL certificates are to be validated. This implementation of CheckValidationResult unconditionally validates any server certificate that is presented. In Step 2, you create an instance of this class and assign it as the global certificate policy for the application.

WARNING: this code should not be used in a production environment, as it will allow your client to connect to any SSL server, trusted or not.

The Mindreef Team | 9:27 AM

We have discovered that the SOAPscope sniffer feature is not functional under Windows XP Service Pack 2. The sniffer is used to automatically capture SOAP network traffic. SOAPscope's proxy and port-forwarding features are unaffected, so users will still be able to capture messages.

The problem is due to the fact that XP SP2 currently restricts the "localhost" address to IP address 127.0.0.1. On most operating systems (including all earlier version of Windows), localhost actually refers to the range of addresses from 127.0.0.0 to 127.0.0.255. SOAPscope makes use of this property for internal communication purposes.

We are currently monitoring this issue. We expect that Microsoft will restore the meaning of localhost soon, as this problem affects a number of third-party software products. If Microsoft does not change XP SP2, it will be necessary to change this aspect of the internal architecture of SOAPscope. We apologize for the inconvenience this causes our users.

UPDATE: Microsoft now has a Hotfix for this issue that is available upon customer request by phone. Details are in Microsoft Knowledgebase article 884020. We have found that the fastest way to get a link/password to the Hotfix is to call 1-800-936-4900 (Microsoft Professional Support) and request the hotfix described in article 884020.

UPDATE 2: Microsoft has now made this hotfix publicly available. Thanks to Eric Schönholzer for letting us know!

Please note that these notes apply to SOAPscope 3.0 SP1. SOAPscope 3.0 SP2, which has just been released, incorporates this fix, so if you have SP2, no action is necessary.

In late February, WS-I posted an update to the C# implementation that causes the following error when it is run from SOAPscope:

The WS-I Test Tool failed to run properly.
Could not read configuration file: C:\Program Files\Mindreef SOAPscope
3.0\temp\in1078433266539.xml Specified test assertions file does not exist.

 

This problem occurs with C# WS-I analyzer version 1.0.1.7 (download file WSI_Test_CS_01.00.01.0008_bin.zip). Version 1.0.0.1 (download file WSI_Test_CS_1.0.2_bin.zip) works correctly.

To work around this problem, either use the Java implementation of the test tools, or edit wsitemplate.xml in the 'conf' subdirectory of your SOAPscope installation as follows:

Change the section that looks like this:

<wsi-analyzerConfig:testAssertionsFile>
    %%ASSERTION_FILE%%
</wsi-analyzerConfig:testAssertionsFile>

to this:

<wsi-analyzerConfig:testAssertionsFile>
    C:\wsi-test-tools\Common\profiles\BasicProfileTestAssertions.xml
</wsi-analyzerConfig:testAssertionsFile>

where C:\wsi-test-tools is the path to your WS-I tools installation.

 

The C# WS-I Test Tool version 1.02 must have a WSDL to perform analysis, or else it it will trigger a 1701 error for every message that is also being analyzed.

If you attempt to run the C# tool manually for any reason, you must run it from the directory the exe is deployed into.

If you attempt to run the Java tool manually, do not forget to set your WSI_HOME environment variable.

For both the Java and C# WS-I Test Tools, correlation is done by endpoint. To correlate, the service URL in the request message HTTP command line must match the soap:address location in the selected WSDL. If these do not match, the message will not be analyzed. To force correlation by overriding the location specified in the WSDL, modify wsitemplate.xml in the 'conf' directory of your SOAPscope installation. First, back up wsitemplate.xml. Next, in the wsdlReference tag, include a tag, whose content is the endpoint the messages were logged against. This will force them to be related to the WSDL you choose for analysis. To resume automatic endpoint correlation, replace wsitemplate.xml with the backup file.

To set SOAPscope as the HTTP proxy in SOAP::Lite, set the $ENV{HTTP_proxy}
variable to the SOAPscope machine name at port 5049:

use SOAP::Lite;
$ENV{HTTP_proxy} = "http://SOAPscopeMachine:5049/";

We have made the documentation and release notes for SOAPscope Personal 1.0 available online.

A tip of the antenna to Jon Udell for his article that reminded us of the importance of doing this.

To get a gSOAP client to proxy through SOAPscope, use code similar to the following prior to making the SOAP call:

struct soap soap;
soap_init(&soap);
soap.proxy_host = "SOAPscope_machine_name";  // or IP address
soap.proxy_port = 5049;

 

The Mindreef Team | 10:51 AM