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.
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 Basic Authentication to identify a user to a service.
Taverna supports the portion of the WS-Security standard that refers to username and password authentication. Depending on a 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 also 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.
You as a user do not have to worry about these things too much - service provider will tell you what authentication scheme they require and you will merely have to tick some boxes in Taverna and provide you username and password, which can be remembered by the Credential Manager.
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 a client and a server 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, Java has its own list of trusted certificates (that belong to trusted CAs) saved in a special truststore file somewhere on your hard drive. This enables you to open an HTTPS connection from Java to a service whose certificate is signed (i.e. vouched for) by one of the built-in trusted CAs. Taverna’s Credential Manager is also making use if this truststore – see the section on Credential Manager for details.
Java Cryptography Policy
Cryptography is the "art" of making sure that:
- the messages you exchange with a service provider are confidential,
- you are communicating only with trusted service providers (and not some bogus sites), and
- that service providers know who you are as well.
By default, Java comes with a security policy that lets you use only limited-strength cryptography. This means that, for example, you can only use short (an therefore not-so-secure) keys for encrypting messages and only shorter passwords. The reason why Java by default only comes with limited-strength cryptography support is due to import control restrictions in some countries, where unlimited-strength cryptography is classified as a “weapon technology”.
Obviously, we want Taverna to use the strongest possible security protections available. This is possible by downloading and installing the ‘Unlimited Strength Java Cryptography Extension’ policy from the Java's Web site (see below for links) in place of the default restrictive policy shipped with Java. Replacing the policy effectively switches on the “strong” cryptography in Java.
Java’s security policy consists of two files located in:
<java-home> is the
jre directory of the Java Development Kit (JDK) or the top-level directory of the JRE (Java Runtime Environment) on your system. You need to replace both of these files with their “unrestricted” versions (note that the policy file names remain the same).
Make sure you also back up the files you are replacing, just in case.
To verify correct installation and identify the correct
lib/security/ folder, run this workflow after restarting Taverna:
Not installing these files will cause the security (and Credential Manager) in Taverna not to function properly. We strongly advise installing the strong security policy before attempting to using any secure services.
If you switch to another Java version you would have to install the policy files again in the appropriate directory of your new Java installation.