This document contains a set of observations made while updating the "security bits" in Taverna 2.3 and porting it to the Command Line Tool 2.3.
Prior to 2.3, the following secure services could be invoked from Taverna:
- Services requiring HTTP Basic/Digest Authentication from REST, WSDL and Beanshell (e.g. get page from URL ...) activities by means of Java Authenticator that read passwords from the Taverna's Keystore.
- Web services requiring WS-security with username and password authentication and optionally a timestamp (WSDL activity).
- Services requiring HTTPS connections with server authentication only (from WSDL, REST, Beanshell activities) by setting Java's default SSLSocketFactory to read from Taverna's Truststore (and in future from the Taverna's Keystore as well for client authentication) and setting the java.net.ssl.trustStore* system properties to Taverna's Truststore.
- Authenticating users to services using HTTPS client authentication was not possible.
Some observations on how/where from various activities obtain the necessary credentials and what potential problems may arise:
- Services that use standard Java's URLConnection to make connections and require HTTP authentication will work in general from Taverna (e.g. from Beanshell activity). They will pick the username and password pairs from Java Authenticator that is linked to Taverna's Keystore. HTTPS will also work as we set the Java's default SSLSocketFactory to use Taverna's Truststore.
- REST activity use Apache HTTP client libraries that seem to respect Java's Authenticator for HTTP Authentication and Java's default SSLSocketFactory that is set to use Taverna's Truststore.
- WSDL activity does not respect Java's Authenticator for HTTP Authentication but we have a way to set the username and password on an axis Call to make this work (not that HTTP Digest Authentication does not work for WSDL activity, just HTTP Basic). Similarly, we have a way to pass username and password for WSDL activities requiring WS-Security authentication. WSDL activity also does not respect the default SSLSocketFactory that we set to use Taverna's Truststore - it seems to be reading from system properties java.net.ssl.trustStore* and java.net.ssl.keyStore* and creating their own SSL sockets! Not quite sure if this will mess up Taverna's SSLSocketFactory and overwrite what we have set as default. Getting HTTPS to work with Web services means setting the java.net.ssl.trustStore* and java.net.ssl.keyStore* properties to point to physical Taverna's Truststore and Keystore on a disk. These files need to be JKS-type keystore whereas Taverna's Keystore is of BouncyCastle BC-type. But this was OK in 2.2 as Keystore is needed for HTTPS client authentication which was not supported anyway (read more on this in the next section). Taverna's Truststore was changed to be of type JKS for the solely reason of supporting HTTPS connections.
- In the Workbench, users can constantly update their Taverna's Truststore/Keystore and we try to sync these with the Taverna's SSLSocketFactory as much as possible. The problem seems to be that one the SSLSocketFactory is initialised with a truststore/keystore any updates to them are not being taken into account so we have to constantly refresh Taverna's SSLSocketFactory. This may cause some services to fail sometimes if the update has not been propagated. Solution? Restart Taverna and hope that this was the problem.
- More serious problems may arise from services messing with Java's default SSLSocketFactory (and overwriting the one that we set from Taverna) or modifying the java.net.ssl.trustStore* and java.net.ssl.keyStore* system properties. Example of such services are caGrid services. In general, we'd like services to stay clear of touching anything about SSL in Java to give them a chance of working from Taverna.
- It seems that if we have two security realms on the same server that use HTTP Authentication, e.g. http://localhost:7070/examples-basic-authentication/ and http://localhost:7070/examples-digest-authentication/, and want to access them both from Taverna with different usernames and passwords - authentication will fail for one of them as Taverna remembers on of them for the whole http://localhost:7070/ and then tries to reuse it for another service as well.
We are making the Command Line Tool aware of Taverna's Credential Manager in order to enable secure workflows that were working in Taverna 2.2 to work from the Command Line Tool as well. For this, we have introduced 2 new command line parameters that can pass a path to the directory with Credential Manager files and a master password for it. We have to change Credential Manager to be initialised from an arbitrary location on a disk rather than from a fixed/default one in <TAVERNA_HOME>/security as in Taverna 2.2.
In Taverna 2.3, we also aim to add the option for services to use HTTPS client authentication:
- This means feeding Taverna's SSLSocketFactory with Taverna's Keystore and making it the default one in the Java VM (this will sort out HTTPS client authentication from REST and Beanshell activities). We also need to set java.net.ssl.keyStore* properties to point to the JKS version of Taverna's Keystore (this will hopefully sort out HTTPS client authentication from WSDL activities). This is similar to what we have been doing so far with Taverna's Truststore. As we now need JKS-type keystore for HTTPS client authentication, we might as well make the Taverna's Keystore JKS-type in the fist place instead of using the BC-type. The downside is that JKS keystores are less secure - they are only integrity protected whereas BC ones are also encrypted. And we would need to change the Credential Manager UI as it uses some properties from BC keystores (e.g. last modified date of an entry) that are simply not available in JKS-ones. The upside is that we do not have to convert from BC to JKS all the time when updating the Taverna's SSLSocketFactory.
- HTTPS client authentication requires clients private key to be loaded to the Taverna's keystore together with the full certificate chain. This can be currently done from the Workbench by importing the whole lot from a single PKCS#12 file/keystore.
- Another thing that needs to be investigated regarding HTTPS client authentication is if we have more than one private key in the Taverna's Keystore, would HTTPS connections cope with this and find the right key for the connection.
- Previously, we were linking private keys to service URLs they should be used for. However, if Java can pick the right key for an HTTPS connection (by trying all of them present in the Keystore) than we do not need this any more. Thus more changes to the UI.
Finally, we need to be able to copy users old credentials from Taverna 2.2 into 2.3 and cope with a possible change in Keystore format (JKS vs BC).