3.5+53.3
Daemon security considerations

Anybody with access to the QF-Test daemon can start any program on the daemon machine with the rights of the user account that the daemon is running under, so care should be taken to only allow trusted users to connect to the daemon.

Of course the QF-Test daemon should always be run on a machine that is protected from outside access by a firewall. If all users that can access the machine behind the firewall are trusted, that is sufficient. If the set of trusted users needs to be limited further, please read on.

By default the QF-Test daemon uses SSL to secure the RMI connection. However, unless you take additional precautions, this only means that the network traffic between the daemon and its client is encrypted. To restrict access to certain users, one further step is required.

Setting up SSL communication can be very complex. One usually has to learn about keys, certificates, certificate authorities, chains of trust etc. Fortunately, this is a very special case, and the fact that once a user has access to the QF-Test daemon he also has control over the daemon's machine means that there is no distinction between the daemon administrator and a daemon user. Without going into details, QF-Test normally uses a single keystore file with a single self-signed certificate on both daemon and client side. More complex scenarios are possible but beyond the scope of this manual. The default keystore file is named daemon.keystore and provided in QF-Test's system directory or the version-specific directory. By creating your own keystore as described below you can ensure that only users that have read access to that keystore file can interact with the daemon.

Creating your own keystore

To create the keystore file you need a current JDK version 1.5 or higher, a JRE is not sufficient. In a shell or console window, execute the following command (you may need to prepend the path to the keytool program which resides in the JDK's bin directory):

keytool -keystore daemon.keystore -genkey -alias "qftest daemon"
          -keyalg DSA -validity 999999
Example 53.1:  Creating a keystore for secure daemon communication

For further information about the keytool command please see http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.htm.

When asked for the password for the keystore enter 123456. When asked for your name or organization, feel free to provide answers or not. For QF-Test these don't make any difference. Of course you can provide a secure password instead of 123456, but that will only complicate starting the daemon and its client and not contribute much to security. You could also use a shorter validity, but in case the keystore file gets into the wrong hands, all you need to do is set up your daemon and users with a new one, so the old one becomes useless.

Specifying the keystore

You have several options to tell QF-Test to use your keystore instead of the default one:

In case you specified your own password for the keystore you also need to specify that via the command line argument -keypass <keystore password>.

In case you would like to start the daemon without any SSL support, for example to interact with a QF-Test version older than 3.5, either remove the file called daemon.keystore from QF-Test's version specific directory or use the command line argument in the form -keystore= to specify no keystore.

Specifying the keystore on the client side

If you use qftest -batch -calldaemon to access the daemon or script nodes from within QF-Test, the options for the client are the same as for the daemon.

To access the daemon over SSL from your own code via the daemon API you must set the System properties javax.net.ssl.keyStore and javax.net.ssl.trustStore to the keystore file and javax.net.ssl.keyStorePassword to the password for the keystore file. See section 53.2 for details about the daemon API and section 23.2 for examples.