Security in Taverna
Security in Taverna refers to invoking services (from inside workflows) that employ some sort of security protections.
There are two types of security protections that service providers normally use to protect their services and that are supported by Taverna. The first is to require users to authenticate to remote services. This is to let the service providers know who is using their service. The second is to make sure that the connection between your computer running Taverna and the remote service Taverna is invoking on your behalf is confidential, i.e. no one can see data being passed between.
You as a user do not have to worry about these things too much – service provider will tell you what security scheme they require and you will merely have to tick some boxes in Taverna and provide your credentials for authentication, which can be remembered by Taverna’s Credential Manager. Credential Manager is Taverna’s utility for safe-keeping your credentials and certificates, like a secure electronic valet.
There are various authentication schemes around. Taverna supports authenticating users via HTTP Basic, HTTP Digest and WS-Security schemes.
HTTP Basic Authentication
The Hypertext Transfer Protocol (HTTP) is a networking protocol most commonly used to communicate with services over the Internet.
HTTP Basic Authentication is an authentication scheme of the HTTP protocol that allows you to authenticate to the service you want to invoke by means of username and password.
Username and password are included in the HTTP headers in plaintext, which means they are not encrypted or protected in any other way. For this reason, services using this type of user authentication will also typically run behind HTTPS, which will encrypt the traffic between the service and the client (Taverna) and protect your username and password while in transit over the Internet.
An example workflow using HTTP Basic Authentication can be downloaded from myExperiment.
HTTP Digest Authentication
HTTP Digest is very similar to HTTP Basic Authentication. The only difference is that the username and password that are included in the HTTP headers are not in plaintext but are somehow scrambled (digested), making it harder for someone to guess them even if they intercept the HTTP traffic.
Even though slightly more secure than HTTP Basic, this scheme is still often combined with the use of HTTPS to give it extra protection.
An example workflow using HTTP Digest Authentication can be downloaded from myExperiment.
Web services typically operate by exchanging Simple Object Access Protocol (SOAP) messages with clients over HTTP. SOAP is an XML-based protocol/language.
WS-Security is a standard that specifies how certain security information (e.g. username and password) can be embedded inside a SOAP message and passed to a Web service over the Internet. It provides an alternative way to HTTP Authentication for identifying a user to a service.
Taverna supports the portion of the WS-Security standard that refers to username and password authentication. Depending on the remote service’s settings, Taverna will add your plaintext or digest password as part of SOAP messages sent to that service. Plaintext means that your password is simply sent “as is” – it is not “scrambled” or encrypted before sending. If someone got hold of the SOAP message containing a plaintext password they would be able to see it. Digest means that your password is scrambled in some way before placing it in a SOAP message and this would make it harder for someone to “guess” your password if they got hold of the SOAP message carrying it.
Sending passwords like this inside SOAP messages over HTTP is not very secure (even if passwords are digests and not plaintext). For this reason, services typically also use HTTPS to protect the confidentiality of SOAP messages while in transit. This makes it (almost) impossible for eavesdroppers to see what is inside the SOAP messages.
In addition, some Web services may also require a WS-Security timestamp (a date and the time) to be added to SOAP messages for security purposes. Taverna is capable of doing this for you. This helps services fight replay attacks, since they can ensure that messages are “fresh” and not “replayed” by checking the timestamp.
An example workflow using WS-Security Authentication can be downloaded from myExperiment.
HTTPS is the most commonly used security protection among services. The use of HTTPS is indicated by a service’s URL starting with
https:// instead of
HTTPS is a secured version of the HTTP communication protocol and provides a connection between your machine and a remote service that is confidential (i.e. private, no one can eavesdrop it). It also verifies the identity of the server by means of a digital certificate – the server must possess a valid certificate issued by a trusted Certificate Authority (CA), such as the Verisign, for the HTTPS connection to be opened successfully.
All modern Web browsers include a pre-defined list of trusted CAs (e.g. for Mozilla Firefox, see http://www.mozilla.org/projects/security/certs/included/). That means that if you were browsing a Web site which URL started with
https://, your browser would first verify if the site’s certificate was among trusted certificates or if it was signed by one of the built-in CAs. If yes – it would proceed to that site. If not, it would ask you if you wanted to trust it. By answering yes, the browser would remember this site’s certificate as trusted and would not ask you next time.
Similarly, Taverna has its own list of trusted certificates (that belong to trusted CAs). This enables you to open an HTTPS connection from Taverna to a service whose certificate is signed (i.e. vouched for) by one of the built-in trusted CAs. Similar to you username and password pairs, Taverna’s Credential Manager is used to store these certificates. You can view, add or remove these certificates to suit your needs.
An example workflow using HTTPS can be downloaded from myExperiment.