Authentication and User Management

Content

LDAP Settings

Ada does not store any passwords but rather relies on LDAP for authentication. Several LDAP settings are available, which all start with the ldap prefix (e.g. ldap.dit):

  • host refers to the host of an LDAP server. Defaults to localhost. Normally set by the environmental variable ADA_LDAP_HOST (in set_env.sh for production).
  • port of the LDAP server. Defaults to 389.
  • bindDN is the DN for the bind operation.
  • bindPassword is the password for the bind operation. Normally set by the environmental variable ADA_LDAP_PASSWORD.
  • dit is the LDAP root directory used for authentication. In particular, the dit is combined with an user id as a suffix: uid=$id,$dit that is passed to LDAP together with a password during authentication.
  • groups are the names of the LDAP groups (defined as a sequence), in which the requested Ada users reside. Note that this setting is used solely for an automatic import of users form LDAP to Ada. Defaults to [].
  • mode of the LDAP server with possible values: remote to use a (normal) standalone remote server, local to start an in-memory local server, and none to disables LDAP completely. Defaults to local.
  • debugusers indicates whether debug users (admin and basic) should be enabled. Defaults to false. Warning: once enabled the admin and basic users can log in without any authentication using /loginAdmin and /loginBasic endpoints, which is fine for local (restricted) deployments but should be absolutely avoided for public use!
  • encryption used for the LDAP connection. Can be either ssl, starttls, or none. Defaults to none, which means client certificates are disabled and server certificates are always trusted.
  • trustStore is a location of certificates from trusted Certificate Authorities (optional).
  • connectTimeout in milliseconds (optional).
  • responseTimeout in milliseconds (optional).
  • pooledSchemaTimeout in milliseconds (optional).
  • abandonOnTimeout in milliseconds (optional).
  • recursiveDitAuthenticationSearch if set to true an LDAP sub-search authentication is enabled. This experimental feature first traverses all sub entries of the dit path. If it finds a requested user it feeds its path (as a suffix) for the authentication together with the user id. Defaults to false.


In nutshell, there are two basic scenarios:

1. if you don't have an LDAP server, don't need authentication, and want to use dummy admin and basic users you can simply set the following lines in custom.conf: 

ldap {
    mode = "none"
    debugusers = true
}
or 
ldap {
    mode = "local"
    port = "65505"
    debugusers = true
}


2. If you have an existing LDAP server you want to authenticate against you need to configure the host and bind password environmental variables in set_env.sh 

export ADA_LDAP_HOST="ldap.north.edu"
export ADA_LDAP_BIND_PASSWORD="XXX"
and set the following lines in custom.conf 
ldap {
    dit = "cn=accounts,dc=north,dc=edu"
    groups = ["cn=ada-group,cn=groups,cn=accounts,dc=north,dc=edu"]
    bindDN = "uid=ldap-reader,cn=users,cn=accounts,dc=north,dc=edu"
}
or without environmental variables (purely in custom.conf) as 
ldap {
    host = "ldap.north.edu"
    dit = "cn=accounts,dc=north,dc=edu"
    groups = ["cn=ada-group,cn=groups,cn=accounts,dc=north,dc=edu"]
    bindDN = "uid=ldap-reader,cn=users,cn=accounts,dc=north,dc=edu"
    bindPassword = "XXX
}
The currently used LDAP settings can be reviewed by clicking on LDAP Settings located in the Admin menu (see the screenshot on on the right).

Basic User Management

User management actions admins can conveniently perform:

  • Filter Users by Permission by Admin → Users → Actions → Filter by permission and entering a permission prefix. This function is especially handy if you want to obtain a list of all the users who have access to a certain data set, in which case DS:[data set id] must be entered (see the section Permissions bellow).

Permissions

Admins have access to all the data sets and can perform all the actions throughout the application. On the other side, all non-admin users need to have explicitly assigned permissions to able to access specific data sets, perform specific actions on those data sets, and execute runnables. Note that basic users can not execute or manipulate any data set imports or transformations, or manage other users' permissions (obviously).


For Data Sets

All data set permissions start with DS: prefix and can be fine grained to the level of individual actions following the hierarchy: DS:[data set id].[controller].[action].

The [controller] corresponds to an actual web controller, which serves actions for the tabs or menu options in the top bar:
  • dataSet: Views and Analytics
  • field: Dictionary
  • category: Categorical Tree
  • filter: Setting → Filters
  • dataview: Setting → Views
  • classificationRun: Analytics → ML Classification → Standard
  • regressionRun: Analytics → ML Regression → Standard
  • temporalClassificationRun: Analytics → ML Classification → Temporal
  • temporalRegressionRun: Analytics → ML Regression → Temporal
Data set permissions can by assigned by choosing → Custom and selecting a desired data set id, controller name, and action. Note that a wildcard ALL can be selected as a controller or action.
Examples:
  • DS:ml.eeg_eye_state.dataset.exportViewRecordsAsCsv gives a user right to exportViewRecordsAsCsv for the data set ml.eeg_eye_state.
  • DS:ml.eeg_eye_state.classificationRun gives a user right to invoke any actions of the controller classificationRun of the data set ml.eeg_eye_state.
  • DS:ml.eeg_eye_state gives a user full rights to perform any action (of any controller) on the data set ml.eeg_eye_state. Note that Setting → General is accessible only for admins and also each user can edit (or delete) only the filters and views that he/she created.

In a nutshell, there are three common permission scenarios facilitated by the following functions:

  • Standard (recommended) - invoked by → Standard.
    All standard actions are allowed: views, analytics, filters, and views, but no metadata manipulation (e.g., dictionary and categorical tree) and no ML. In particular, the individual permissions/actions are: 
    dataSet
field.find
category.idAndNames
dataview
filter
  • View-Only - invoked by → View-Only.
    User can only see already existing views and filter them. The allowed actions are: 
    dataSet.getView
dataSet.getDefaultView
dataSet.getWidgets
dataSet.getViewElementsAndWidgetsCallback
dataSet.getNewFilterViewElementsAndWidgetsCallback
dataSet.generateTable
dataSet.getFieldNamesAndLabels
dataSet.getFieldTypeWithAllowedValues
dataSet.getCategoriesWithFieldsAsTreeNodes
dataSet.getFieldValue
dataview.idAndNamesAccessible
filter.idAndNamesAccessible
  • All - invoked by → Custom and choosing ALL as a controller.
    User can perform all actions for a given data set.


For Runnables

All runnable permissions start with RN: followed by the full name of a selected runnable class: RN:[runnable class name]. Such permission allows a given user to execute the runnable.

Runnable permissions can by assigned by choosing and selecting a desired runnable name.