Overview

OpenCGA Catalog is an authenticated environment. This means that a typical user would need to be authenticated in order to start working with it.

The admin will need to define whether Catalog user registration is going to be public or private before OpenCGA is deployed. If the admin defines a public user registration, any user with access to the webservices will be able to create their own user and start working. However, in many situations, the admin will decide to make it private, being only the admin who will have the rights to create new user accounts. This can be easily modified by changing the configuration file and restarting the service.

User creation

As for version 1.x, the admin has two different ways of defining the account type of a user (FULL or GUEST). Basically, a user with a full member account will be able to define its own projects and studies, whereas a user with a guest member account will not. However, it is worth to mention that although users with guest accounts will not be able to define new projects, they will still be able to create new files, samples... if he/she has the proper creation permissions in other else's user study. The permissions are explained in Catalog Permissions.

There exists basically two different ways of defining new user accounts depending on the authentication system the user will be authenticated against.

Catalog

The most typical use case would imply creating new users that will be authenticated using our own authentication implementation. The admin will just have to use the admin command line to create a new user. In this case, the user information and user password will need to be provided. The password will be encrypted and safely stored in our database.

Import users from other authentication system

A different way of defining new users in Catalog would be using the import command line. This command line will basically connect to an external authentication* system (properties defined in the Catalog configuration file) and fetch the relevant user information in order to create a new user entry in our database. In this case, passwords are not asked nor stored in the database.

This same command line can also import groups of users from the external authentication origin and, optionally, synchronise that group with an internal group within a study. This has several advantages:

• Import big batches of users that belong to one same group in the external authentication system.
• The external group is synchronised with the internal group within the study, which means that every time an external user logs in, OpenCGA will check if the user belongs to any synchronised group to remove, add or keep that user from the Catalog group. By doing so, we are 100% sure that if a user is removed from a synchronised external group, that user will not be able to do any action that group was granted to do.

Login system

Like it was mentioned in the overview, Catalog is an authenticated environment. Because users can only exist in Catalog itself but they could also come from other external authentication systems, we need to store each user's authentication method. This is stored in the user data model, in the account object. Catalog users will be authenticated using our implementation as we have the encrypted password stored. However, users coming from an external authentication system will be authenticated against it.

OpenCGA uses JSON Web Tokens (JWT) standard to provide users with a unique and digitally signed token. The default expiration time of the tokens is 30 minutes but can it can be easily modified in the configuration file. When the authentication is successful, a JWT token is generated and provided. This token will be needed by the user to perform any action from that moment on.

Group definition

In order to make sharing things with other users easier, groups are also taken into account. Each group will contain a list of users belonging to that group and are defined at study level (see here). This means, that different studies could have defined the same group name but some users might belong to that group in one study and not in the other.

At first, only the study owner is allowed to create groups and add users to them. However, the owner, might also choose some users to be able to do this actions as well (authorisation page).