Configuration

In order to be able to authenticate using other authentication origin credentials, it will be necessary defining some parameter present in the configuration.yml file. In this section, it will be possible defining as many authentication origins as needed. 

authenticationOrigins:
- id: ldap1
  type: LDAP   # At the moment, only LDAP type is supported
  host: ldap://localhost:9000
  options:
    usersSearch: dc=ge,dc=co,dc=uk
    groupsSearch: ou=general,ou=groups,dc=ge,dc=co,dc=uk
- id: ldap2
  type: LDAP  # At the moment, only LDAP type is supported
  host: ldap://localhost:8000
  options:
    usersSearch: dc=ge,dc=co,dc=uk 
    groupsSearch: ou=general,ou=groups,dc=ge,dc=co,dc=uk

In the below example, we would be defining two different LDAP authentication origins (defined in the type variable). The first one receives the id ldap1 and the host is in ldap://localhost:9000, whereas the second one has the id ldap2 with a different host.

The usersSearch and groupsSearch fields are of real importance. In this string fields admins will have to define the naming context to search for users and groups respectively in that authentication origin.

Supported Operations

Once OpenCGA is installed with the proper configuration file, the next step would be adding users from these authenticated origins. To do this, two admin command lines have been added to opencga-admin.sh script.

Import users

The command line needs the authentication origin id, which in this case would ldap1 or ldap2, and accepts several optional parameters. Admins might opt to provide a list of comma separated users using -u, --user and/or a group already defined in their authentication origin containing a list of users that will be directly imported into OpenCGA.

Admins can also define additionally how this new OpenCGA user account will be, the expiration date (--expiration-date) or the type (--type). There are basically two different types of accounts: guest and full. The main difference between full and guest is that users with a full account are able to create their own projects and studies. However, guest accounts cannot create anything in OpenCGA unless they have been granted permissions to manipulate other user's projects and studies. 

Example: Let's imagine that one PI has created a different project/study for every different research the PI is doing. The PI will be able to import other users from an external authentication origin, but most probably, the type of the account will be guest. This way, the PI is sure they cannot create anything in OpenCGA. However, the PI will give permissions subsequently to those users. Maybe some users will be able to create new things inside the study, others will only be able to read some information...

The last thing worth explaining is the parameters --study-group and -s, --study. These parameters will allow the admin to create one group in one study of OpenCGA containing the list of users imported all in one command line.

Sync groups

The aim of this command line is the synchronization of users between one (or more) of the groups in the external authentication origin and one (or more) of the groups defined in one study of OpenCGA.