Study ACLs

Remember that you can always check the Catalog code that implements OpenCGA's ACLs permission system in our official publicly available GitHub repository.

Here you will find the list of permissions that can be granted to a member (user or group) in OpenCGA. Thanks to the ACLs system, permissions can be assigned to almost any entry level (except for User and Project).

How it works

A list of the basic permissions and their explanations can be found in the list below:

  • VIEW: Give permission to access in read-only mode to the entry (study, file, sample...). WRITE: Give permission to create and update that kind of entries within the study. This do not include permissions to modify annotation and/or annotation sets. Those actions will need additional permissions.

  • DELETE: Give permission to delete that kind of entries.

  • ANNOTATIONS: In Sample, Individual, Family and Cohort we have three additional permissions to deal with annotations.

Files deserve a special treatment as they not only exist in the database, but also physically in the file system. The special permissions added for files are the following:

VIEW_FILE_HEADER: Give permission to retrieve just the header of a file. DOWNLOAD_FILES or DOWNLOAD: Give permission to download the whole file.

  • VIEW_SAMPLES

  • WRITE_SAMPLES (implies: VIEW_SAMPLES)

  • DELETE_SAMPLES (implies:VIEW_SAMPLES, WRITE_SAMPLES)

  • VIEW_SAMPLE_ANNOTATIONS (implies: VIEW_SAMPLES)

  • WRITE_SAMPLE_ANNOTATIONS (implies: VIEW_SAMPLES, VIEW_SAMPLE_ANNOTATIONS)

  • DELETE_SAMPLE_ANNOTATIONS (implies: VIEW_SAMPLES, VIEW_SAMPLE_ANNOTATIONS, WRITE_SAMPLE_ANNOTATIONS)

  • VIEW_AGGREGATED_VARIANTS

  • VIEW_SAMPLE_VARIANTS (implies: VIEW_SAMPLES, VIEW_SAMPLE_ANNOTATIONS, VIEW_AGGREGATED_VARIANTS)

Permissions Templates

OpenCGA Catalog implements two Permissions templates: predefined generic roles that capture a list of defined permissions. The permission templates can be granted to either users or groups.

  • analyst: The member (user or group) will be given full READ and WRITE (not DELETE) permissions for all the entries related to the study. These users will be able to view and do modifications on all the data that is related to the study.

  • view_only: The member (user or group) will be given full READ permissions.

Special cases

Permissions can be given to any concrete entity (file, sample, cohort...) to deny or grant access to just one concrete entry. This is always true except for a few exceptions in which we might propagate those same permissions to other entries:

Files

File entry might be of type file or folder (directory). Permissions assigned in folders are propagated to all the children (files and folders) recursively.

Individuals/Samples

Individuals are really strongly related with samples. So every time permissions are given to an individual, the same permissions can be applied to all the related samples if the user sets the 'propagate' field to True, and vice-versa.

Give public access to non-existing users

Catalog has one special user for this purpose represented with * symbol. Anytime a user tries to fetch anything and no session id is provided, Catalog will treat that user as *. By default, only authorised users will have access to data. However, study managers can still define permissions for non-authenticated users assigning permissions to the "user" *.

Last updated