Skip to end of metadata
Go to start of metadata

Additional Installation Information

Firewall Requirements

Taverna Server is a fairly network-intensive application, and the workflows it runs typically assume that they have access to a wide range of external ports by default. Because of that, it is recommended that outgoing ports on the system running Taverna Server be mainly not blocked (a few exceptions are reasonable, such as preventing access to external SMTP services). In particular, it is not safe to just assume that all web services accessed by workflows run on “standard” ports like 80 or 443; this is not seen in practice.

For incoming ports, we recommend restricting them as much as is practical. In particular, we note that port 1099 is used by the service along with a substantial number of high-numbered ports: none of those need any access from outside the host system. The only ports that need to be opened are those that handle incoming user requests: in the default configuration of Tomcat, this would be port 8080 for HTTP traffic and 8443 for HTTPS traffic. (You will probably want to keep some other ports at least partially open for administration traffic, e.g., 22 for ssh access, but this is formally outside the scope of this document: Taverna Server itself does not need that.)

If you configure your firewall (or some sort of proxy) so that the host, port and web-application root that the user sees is not that which you are actually running the service on, you should set the default.webapp application parameter — typically via a deployment parameter — to a URL fragment giving the host, port and webapp root that you wish to use. (Taverna Server forces the protocol used separately.)

Details of Configuration

Deployment of web applications into Tomcat can be done through multiple mechanisms, notably through command line tools and through Tomcat's online administration interface. This document describes the latter mechanism. Note also that we currently only support the use of Taverna Server within a Unix environment (e.g., Linux, Mac OS X); there is no reason in principle why the code should not be adaptable to Microsoft Windows, but there is currently no impersonation module written to integrate Taverna Server with that operating platform.

This assumes that you installing into Tomcat 6 running on top of Java 7; this was tested with Tomcat 7.0.21 over the Oracle JRE 1.7.0_21. Later patch versions from the same major version are recommended, if available. This software has not been fully tested with Tomcat 7.

The configuration of the Taverna Server installation is done by writing a context descriptor document, only some parts of which can be configured afterwards via the management interface. An example of that XML document is below:


The context descriptor is typically in a file called context.xml and there is a sample context descriptor with this distribution, in the context.sample.xml file. There are a substantial number of properties that may be tuned during installation (see below).

The actual deployment is done by giving the actual context location (i.e., the base URL of the webapp relative to the whole Tomcat container) as a separate field, together with URLs (it is useful to use file: URLs for this) to the context descriptor document and the distributed WAR file.

Configuration Property List

This is a list of all the properties that are set by default in the Server (NB: the properties in red are actually unset or commented out by default, but they are all understood). They may be all overridden by the use of context configuration parameters as described above; for example, to override the default local user name, the default.localusername configuration parameter would be set.

The majority of these properties should not be set, as they default to reasonable parameters. The exceptions are:

  • Those used to control how many runs exist and are operating at once. The default.runlimit and default.operatinglimit have reasonable initial values, but must be tuned according to the actual expected workload. They can be set at runtime via the administration web interface and via JMX.
  • Those used to enable optional notification mechanisms; those are all disabled by default unless the required extra properties are set (see below for instructions).


Enabling Notification Options

With the exception of the Atom feed, all the notification methods supported by Taverna Server are disabled by default. They require additional configuration in order to work correctly. This is done through configuration options. Only once all options for a particular notification method are set will Taverna Server enable that method for use. Note that many of these methods require additional services to be deployed or accounts with remote services to be created.



“URL” Scheme




message.cooldown — All the notification methods below except for the Atom feed are subject to rate limiting; this property is the minimum amount of time (in seconds) between two notifications by the same mechanism. The default is 300 seconds (5 minutes).

message.termination.subject — Where a notification mechanism needs to attach a subject to a message, this property contains the value to use. Does not need to be changed unless the service is being adapted to use a language other than English.

message.termination.body — This property contains a template that is used to produce a notification message. The template itself contains {0} to indicate where the terminating run’s ID goes, and {1} (or its derivatives) to indicate where the termination code goes. Does not need to be changed unless the service is being adapted to use a language other than English.



atom.language — Language to claim that the message is published in. Recommended left at default (English of unspecified locale).

atom.lifespan — How many days will a particular notification persist in the feed.

atom.cleaninterval — How often will the code check for whether it can remove a particular notification, in milliseconds.


mailto: — Name of a machine with a suitable relaying SMTP server that all emails will be sent via. Must be set to enable this notification method.

email.from — What account will the message appear to be sent from. Changing from the default is recommended.

email.type — What MIME type will be used with the message. Can be left at the default.



xmpp.server — Name of a machine that runs a suitably-configured XMPP server. Must be set to enable this notification method.

xmpp.user — User name to use when contacting the XMPP server. Must be set to enable this notification method.

xmpp.password — Password to use when contacting the XMPP server. Must be set to enable this notification method.

xmpp.resource — Resource descriptor used to disambiguate messages sent by Taverna Server. Can be left at the default.



sms.service — Address of a RESTful SMS service interface for sending SMS messages. Must be set to enable this notification method. Note that this has only ever been developed against a single service interface[2], and is not guaranteed to work with any other.

sms.user — The user account to use with the above service. Must be set to enable this notification method. Note that creating such an account has some financial implications; these are out of the scope of this document.

sms.pass — The password to use with the above service. Must be set to enable this notification method.

sms.userfield — The name of the field to use for the user name when conveying the message in the POST request. Allows for limited adaptation to other services, but may be left at the default.

sms.passfield — The name of the field to use for the password when conveying the message in the POST request. Allows for limited adaptation to other services, but may be left at the default.

sms.destfield — The name of the field to use for the destination phone number when conveying the message in the POST request. Allows for limited adaptation to other services, but may be left at the default.

sms.msgfield — The name of the field to use for the message content when conveying the message in the POST request. Allows for limited adaptation to other services, but may be left at the default.



twitter.oauth.accessToken — The public part of the OAuth access token to use when authenticating a Taverna Server deployment to Twitter. Must be set to enable this notification method. Note that users must take additional steps to allow the ability to set status messages; this is outside the scope of this document.

twitter.oauth.accessTokenSecret — The private part of the OAuth access token to use when authenticating a Taverna Server deployment to Twitter. Must be set to enable this notification method. Note that users must take additional steps to allow the ability to set status messages; this is outside the scope of this document.


User Accounts

Once you have deployed the server, you can use either JMX or the http://«SERVER:PORT»/taverna-server/admin interface to create and manage accounts. Only accounts with administrative permission can do such management. The initial set of users is loaded into the database from the WEB-INF/security/ file in the deployment package; see the comments in that file for a more complete description of its contents; the file is only used if the user database is empty.

By default, two enabled users are created. One is a normal user (taverna, with password taverna) and the other is an administrative user (admin, password admin). These defaults should be changed after installation, as they are not considered secure by default. More information about the mapping process is in the security summary document.

Configuration of Impersonation

If it is desired to separate each user of Taverna Server from the others, it is necessary to configure impersonation of users. That is, the user account that is running the servlet container (Tomcat, etc.) must have permission somehow to execute code as other users. (If this is not desired, the service should be configured to use the simpler non-impersonating worker factory — see the backEndFactory property above — or the fall-back user identity to use for impersonation should be set in the default.localusername to the same identity as the user account used for running the server.)

This is done by either instructing the service what password is to be used with sudo (typically the password for the account that is invoking the sudo command) or by configuring sudo itself so that the service account is more highly authorized than a normal account. The first style of impersonation, which requires that the service account have a password at all, is enabled by creating a file (in a suitably secured directory) that contains the password as its only content, and telling Taverna Server about it during deployment by giving the full pathname of the file in the secureForkPasswordFile deployment parameter.

The second style of impersonation is done by leaving that parameter unset and instead adding some extra configuration to the system's /etc/sudoers file, as seen below (typically set with the visudo command). Note that conventionally the three parts of the configuration are in separate sections of the file, and that care should be taken during configuration as mistakes can result in a system that is broken. In the example below, we assume that the servlet container is running as the Unix user tavserv and that local user accounts that may be targets for impersonation are all members of the taverna UNIX group.


Care should be taken as without a password specified and without permission to execute as another user, an attempt to create a workflow run will hang instead of failing.

Security in Taverna 2 Server


Taverna Server normally operates in a mode where it executes each user's workflow runs under a user-id that is specific to that user. This keeps the users from seeing each other’s workflow runs by back-door mechanisms, and makes it far easier to apply standard server resource accounting.

In order to do this, it needs to be able to run code (specifically, a Java program) as effectively arbitrary other users. On Unix (currently the only fully supported hosting platform) this is implemented through the use of sudo with a special configuration, which allows the user hosting the Java container special access. Because of this, it is strongly recommended that other web applications be not run in the same container, or that if it is necessary to share webapps that way, the subprocess execution module be instructed where to find a password for use with the sudo thunk.

It is recommended that Taverna Server always be operated in secure mode, with all connections normally being made via HTTPS. Given that this requires that the container be configured with an SSL certificate, it should be noted that a single-host certificate is available from many certificate authorities for extremely limited cost (even free in some cases). Please consult your container's documentation on how to install the SSL certificate and configure the container for HTTPS operation.

If JMX is used for the management interface (depends on the container) it is recommended that it be configured to only accept authenticated connections over SSL. There is also an http://«SERVER:PORT»/taverna-server/admin REST interface to the server, which allows access to the same capabilities; it is only accessible to users which have the ROLE_tavernasuperuser authority granted to them. Not all parts of the configuration can be managed in this way though; some properties are sufficiently fundamental that they can only be set through the configuration of the deployment descriptor.


The communication between the back end workflow executor managers and the front-end webapp is done via RMI, which has been configured to not accept connections from off the local host or class definitions that it does not already know about.

Authorisation of users is done through the use of Spring Security to assign them on each connection a set of security authorities. In particular, the key authorities are:

ROLE_tavernauser — allows the user to access the main operational parts of the server.

ROLE_tavernasuperuser — allows the user to read and write all non-security characteristics of all workflows, and also grants access to the http://«SERVER:PORT»/taverna-server/admin pages.

LOCALUSER_* (where the * is replaced with a local user name) — specifies what local user name the user should be executing workflows as; the prefix (LOCALUSER_) is simply stripped and the remainder is used as a user name. If absent, the default user name (taverna in the default configuration) will be used; two users mapped to the same user name will be able to see each others workflows if they can work out where the job working directories are located, but will not be able to see them inside Taverna Server itself (unless one user grants the other authority to do so, of course).

The default source of authorities is the file WEB-INF/security/ (relative to the directory which is the expanded webapp) that is used to populate the database if that is empty.

Insecure Mode

The server can be switched into insecure mode by editing its WEB-INF/web.xml file so that it pulls its Spring configuration from insecure.xml instead of from secure.xml (the default) via the contextConfigLocation parameter. When editing WEB-INF/web.xml, the webapp must be stopped and restarted for any changes to be noticed. This alternate configuration disabled URI rewriting, restricts the set of users to a single one (taverna with a password taverna) and arranges for execution of workflow runs to be done in the same local userid as is running the host servlet container (Tomcat, etc.)

If you are using this, it is strongly recommended that you place the server behind a strong firewall and portal, and only permit vetted workflows to be used.

Part-Secure Mode

There is a partially-secured configuration as well. This enables the forced use of HTTPS, but disables the use of user separation by the back-end engine, giving an intermediate level of security suitable for the case where the network is not trusted but the permitted users are trusted. You may enable this mode by using partsecure.xml as the value of the contextConfigLocation parameter in WEB-INF/web.xml after installation (the webapp must be stopped while you make this change). Note that because HTTPS is being used, you will still need to configure the servlet container with an SSL keypair for this to work.

Managing the Server

The server is designed to support JMX for management. This allows the use of tools such as jconsole or jvisualvm (with appropriate plugin) to connect to the server so that they can view, chart, and manipulate properties of the server. The exact list of properties is liable to change, but is as follows in this release:

Component: Taverna/Server/Webapp

This is the component that interfaces with the external world.






Whether to permit any new workflow runs to be created; has no effect on existing runs.



Count of currently existing runs.



Count of SOAP and REST calls made to the Webapp.



Whether to put submitted workflows in the log.



Whether outgoing exceptions should be extensively logged.

Component: Taverna/Server/RunFactory

This component is responsible for manufacturing workflow runs and maintaining connections to existing runs. Note that the writable properties typically have sensible values by default.






The names of the currently existing runs.



How many minutes should a workflow live by default?



The full pathname of the script to run to start running a workflow. Must be readable by any user of the system.



The list of additional arguments used to make a worker process.



The mapping of user names to RMI factory IDs.



The full pathname of the Java executable to run.



What was the exit code from the last time the factory subprocess was killed?



How many checks were done for the worker process the last time a spawn was tried. (Larger values indicate problems with system loading.)



The maximum number of simultaneous runs supported by the server. Note that this includes runs that have finished executing but have not yet been deleted.



The maximum number of simultaneous operating runs supported by the server. This is only the runs that are in the Operating state.



The full pathname of a file containing a password to use when running a program as another user (e.g., with sudo).



The host holding the RMI registry to communicate via.



The port number of the RMI registry. Should not normally be set.



The full pathname of the JAR implementing the secure-fork process.



The full pathname of the JAR implementing the server worker processes.



How many milliseconds to wait between checks to see if a worker process has registered.



How many times has a workflow run been spawned by this engine.



How many seconds to wait for a worker process to register itself before causing the creation operation to fail.

Component: Taverna/Server/Users

This is an interface for adding, deleting and otherwise managing user accounts on the server. It does not manage the underlying system accounts, but does allow control over the mapping of users to those accounts. Note that newly created accounts are disabled by default. More information about the mapping process is in the security summary document.






The list of server accounts known about.




Adds the user called nm to the database, with password pw. If cpl is true, set the local user account to be the same as the user name, otherwise use a default set at system configuration time. The user will be a non-admin and disabled by default.


Remove the user called nm from the database.


Get a description of the user called nm from the database.


Set whether the user called nm is an admin or not (according to the boolean, ad).


Set whether the user called nm is an admin or not (according to the boolean, en).


Set what the user called nm will be mapped to as a local user to lu (which must be the name of an account understood by the local system).


Set the password for the user nm to be pw. This implementation stores the value directly in the database.


The server also supports a RESTful administration interface on its http://«SERVER:PORT»/taverna-server/admin resource (a sibling to the main RESTful http://«SERVER:PORT»/taverna-server/rest resource and the Atom feed on http://«SERVER:PORT»/taverna-server/feed). This interface is only available to users who authenticate with admin permissions. Currently, there is no rendering of the interface in a form that is suitable for use

[1] This is always enabled; termination notifications are automatically published to a per-user Atom feed that users cannot post directly to. This feed is located at http://«SERVER:PORT»/taverna-server/feed relative to the webapp root resource.

  • None