 |  |  |  |  |  |  |  |
| Version 8.0.1 |
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.
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):
| ||||
| Example 54.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.
You have several options to tell QF-Test to use your keystore instead of the default one:
daemon.keystore in QF-Test's system directory
daemon.keystore in the
user configuration directory.
-keystore <keystore file>.
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.
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 54.2 for details about the daemon API and section 24.2 for examples.
| | | | | | | Last update: 9/10/2024 Copyright © 1999-2024 Quality First Software GmbH |
