BioCoRE Security Overview
BioCoRE is organized around the concept of projects. A researcher is a member of one or more projects, and only has access to information about those projects. Researchers are unaware of the existence of other projects, and of other researchers with whom they don't share a project.
Another aspect of the BioCoRE research project is the evaluation of how researchers use BioCoRE. To do this, the BioCoRE server collects data about how the researchers are using BioCoRE, by recording a trace of each user's activities in the system. This information is stored in an event database. Periodically, each server attempts to connect the central event server maintained by the BioCoRE research team, and deposits this information using HTTPS into a main BioCoRE event database. The main event server is managed under the same security conditions as the development BioCoRE server.
II. Machine Security
Most internet services, including telnet, ftp, and rlogin, are disabled and the system is continually patched with the latest security patches.
III. User authentication
All accesses to BioCoRE are encrypted using HTTPS. Upon first accessing BioCoRE, the user fills out a registration form, which includes a request for an email address. When the form is submitted, the server generates a random password for the user, encrypts the password and stores the encrypted version in the database An email message tells the user how they may log into BioCoRE using the random password and change it to a password of their choice. On login, the user's password is sent to the server using HTTPS, encrypted, and the encrypted password is compared to the version in the database.
Once a user has logged in, his session is assigned a "session-id". The session-id is a 32-bit number that is passed, usually as a HTTP parameter, along with any accesses. If the user attempts to use an old session-id after already being assigned a new one, they must again provide their user name and password. The session-id becomes invalid when the user either explicitly logs out of BioCoRE or does not access BioCoRE within a required timeframe.
IV. Job Management
Managing remote computational jobs is one of the tools in BioCoRE. The level of automation we have implemented requires that the BioCoRE server have access to the researcher's account on the computational machine, so that the server may deposit and retrieve files and execute commands to run the job and see if it is still running. Unlike most of the information in BioCoRE, account information is privately held by the user, rather than being shared with everyone in the project. Other project members are only aware of the existence of and results from completed jobs.
Job management was first implemented using SSH and associated programs to allow the BioCoRE server access to the researcher's account. First the user tells BioCoRE about his account, by selecting from a list of machines that BioCoRE knows about, and providing their user name and password. This information is transmitted via HTTPS to the server, where it is used to log in to the remote machine using SSH. Once logged in, the server generates an SSH key-pair, and deposits the public key into the researcher's .ssh/authorized-keys file on the remote machine. The private key is stored in the BioCoRE database. At this point, the server forgets the researcher's password, and all further transactions between the server and the remote machine occur using the generated key-pair. Whenever a researcher wishes to prevent BioCoRE from accessing the account, they may do so by removing the public key from their authorized-keys file.
For using Globus, users must have an Alliance certificate, and BioCoRE uses the MyProxy server to gain access on the user's behalf to the Alliance machines.