Mascot Security: privacy settings
It is perfectly possible to share a single Mascot Server between individuals or groups who require privacy for their searches. Mascot Security provides the mechanism to limit access to result reports, databases, and even custom modifications.
Mascot security is not designed to be highly secure – a determined hacker could probably find ways around it without too much difficulty – but it is strong enough for a typical research laboratory environment. Note that none of the information on the Mascot Server is encrypted, apart from passwords, so everything is visible to the system administrator, and anyone else who gains access to the files by means of a file share or some other route. This means that, where multiple groups share a server, it is best if they nominate one person to be the system (and security) administrator.
Security is configured by a browser-based editor, although you can also edit the XML files directly if this is more efficient for a particular purpose. It is good practice to use the administrator account for administration tasks only. If the administrator also runs searches, they should log in as a regular user using a separate account. Mascot security is role based, which means that rights are assigned to groups, not individual users. Users gain rights through being members of one or more groups.
For databases on a shared server, one option would be to start from a default of allow all and deny access to specific databases for individual groups. A safer option is to make deny all the default because, when a group asks the sysadmin to add a new database which they want to be private, the only security change required is to add the new database to the allowed list for one group. If the default is allow all, the new database has to be added to the denied list for all groups except one. If the sysadmin forgets to do this, the database is visible to all. (Allow all corresponds to selecting SEARCH: Allow all fasta databases to be searched while deny all corresponds to omitting it. The denied or allowed list is then specified using SEARCH: Special fasta databases that override the default setting.)
A user will only see a database listed in the search form if they belong to a group that is allowed access. This restriction will also apply to other processes that need to access the Fasta. For example, the result file doesn’t contain complete protein sequences. If a user is able to access a result report that includes matches from a database the user cannot access, they won’t be able to load a Protein View report, because this needs to retrieve the protein sequence from the Fasta in order to generate the report.
Otherwise, result reports are self-contained, and access is controlled by four security tasks
- VIEW: See search results from other people in your own group
- In most cases, you will want to select this. Otherwise, a user can only see searches they themselves submitted
- VIEW: See search results from any user in any group you belong to
- Description follows below
- VIEW: See search results without USERID field
- See all search results that don’t have a USERID, such as searches submitted before Mascot security was enabled or the examples used in the help pages. Should always be selected.
- VIEW: See all search results with a USERID
- See all search results submitted since Mascot security was enabled. This should only be selected for the Administrators group.
The way the second task works is easiest to explain with an illustration. You are teaching a proteomics course where Mascot is used. Pupils should not be able to see each other’s results, so you create a group called pupils where the first task is missing, meaning members can only see their own results. As the instructor, you want to be able to see everyone’s results, so you create a second group called teachers where the second task is selected, and make yourself a member of both groups.
It is OK to select VIEW: Allow user to view the search log for all groups on a shared server. When a user views the search log, they only see searches where they are entitled to view the result report. This minimises ‘clutter’ and avoids the possibility of something being displayed in the log that is confidential, such as the search title.
If users in a group need to be able to submit searches from Mascot Daemon or Mascot Distiller, make sure the appropriate CLIENT: tasks are selected plus GENERAL: View config files using ms-status. Most are self explanatory, but CLIENT: For Mascot Daemon, allow spoofing of another user and CLIENT: For Mascot Daemon, restrict spoofing to the named group(s) deserve some explanation. The first is useful in a core lab, and is described in Using Mascot security to share search results. If you want spoofing on a shared server, you should probably also select the second task, which limits the scope, and only allows users to run searches for other members of their own group. The settings shown here might be a good starting point for a group on a shared server:
You can also make a modification private to selected groups. This only applies to a custom modification, created locally. You cannot make a standard modification taken from Unimod private. In the modifications module of the configuration editor, if you create a modification, you’ll see a privacy tab in the editor. Check the box for private and you will see controls that allow you to select which security groups can see the new modification.
In a future article, we will look at how Mascot security can be used to control usage of server resources, such as limits on the size or type of search, how many searches a user can have running simultaneously, search priority, etc.