Hi everyoneThis is a note to give people here a heads-up on what we're planning to do with security for Taverna Server, based on discussions between myself and Alex Nenadic. Unlike when people are running the workbench, servers are shared resources and that makes security a critical part of making them useful in practice.
COMMUNICATION WITH THE SERVERFor securing access to the server, we plan to leverage the security of the container (i.e., Tomcat in all currently tested installations). This can be configured to use HTTPS to secure the connection, meaning we can then use username and password inside that secure connection to actually do the securing of the server itself. This is Good because these are extremely well tested production facilities. (There's also a potential to use other authentication/authorization systems here, but we don't plan to do them for the next release as they require a lot more complexity elsewhere.)
We plan to allow the use of the username/password to check against the system user database (Tomcat supports this with many variations, e.g., LDAP, Windows domains, etc.) or to allow the use of a single username for all access - we've tested the second of these configurations - and we will provide a way of mapping that to the local user identity to run the workflow as. (There are a few options there, but really they all come down to running as one user or running as the actual user; the other options are exotic and not likely to be supported in the next release.)
Access control to workflow runs will be done initially so that users (other than those explicitly marked as superusers by the system) will only be able to locate, see and manipulate runs that they created. We plan to allow users to name other users to be able to see some of the runs they created, or even manipulate them, but that's likely to be a more advanced feature that doesn't get fully done for the next release (the internal access control system is in place, but the controlling policies and interface to them are as yet simple-minded and safe).
COMMUNICATION BY THE WORKFLOW RUNSThe final stage of dealing with security is allowing workflow runs to make secure connections out to other services. To make this work, we plan to have a Security Context that contains a description of the credentials required and the identities trusted; this will only be visible to the owner of the workflow, even if we expose access to other workflow properties (as hinted at above).
Access keys (whether secrets like passwords or private keys) will be defined by a list of tuples, abstractly like this:
<service URL, credential name, credential type,
credential file, file type, unlock password>
The service URL is what service to use the credential for, the
credential name and type identify what to use within the credential
file, and that file can have its type forced (need to support multiple
types here so that clients can be implemented in many languages).
Finally, there's a password to unlock the credential file; we're going
to assume that that's also suitable for unlocking the credential inside
the file if necessary since *lots* of other tools make that same assumption.
For trusted identities, there will be a set of server defaults that clients can add to. Abstractly, that will be done by manipulating a list of tuples like this:
<certificate file, file type>Note that there's no need to unlock this, as it is a public certificate. That's why it is so much simpler than for access keys. :-)
LONGER TERMWe recognize that the situation where people are uploading private keys and secret passwords to the server is non-ideal. Ideally, we want to support delegatable credential systems (probably through somehow using the login credential to pre-populate the access key parts of the Security Context; probably setting some kind of default entry) but there are sufficiently few deployed services that accept these types of credentials that it's not something that we will implement in the next month or two without significant contributions of effort. And in any case, it will become easier once we have the foundations of the security systems (outlined above) in place.
HEALTH WARNINGThese are just our outline ideas; we welcome feedback before we start writing code to implement it. It's far easier to fix problems when we're still at the design stage. :-)
Donal.
<<attachment: donal_k_fellows.vcf>>
------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb
_______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/about/contact-us/ Developers Guide: http://www.taverna.org.uk/developers/
