mDIS User Management

System administration task.
More system administration
List of 3rd-Party Code dependencies
Roles on "developer" page.

Users and Roles

This page describes how to manage mDIS users and mDIS roles.

These are tasks that are usually performed rarely. Actually, for many DIS customers, the creation of a few generic users is a one-off task. Often, this happens only once, during setup and configuration of the mDIS system.

mDIS always can use its own, small, internal user-database; alternatively it can be connected to an LDAP server. User management needs to be carried out by mDIS users who have been granted specific roles.

User Management GUI

This section describes user management tasks performed after logging into mDIS with your browser.

Creating a New User

and Assignment of User Credentials

mDIS credentials are based on Role-Based Access Control (opens new window) (RBAC).

mDIS Administrators perform registration of a new mDIS user by means of a special-purpose web form, url-path /user/admin/create.

Unlike those webpages and forms that work with science data, this page does not use the mDIS REST API. Instead, the user management pages use the widget sets and the APIs of the Yii framework directly.

However, adding users is a task performed rarely. It must be implemented in a secure manner, so we decided to rely on built-in features of Yii's RBAC capabilities directly. These are provided by 3rd party code-dependency,

2amigos/yii2-usuario | 1.5.1 | Highly customizable and extensible user management-

Password Assignment

The user's password is initially assigned by the mDIS administator, or, if the new user is physically present with the mDIS Admin at registration time, entered by the new user personally.

TBC

At this time the mDIS user cannot change the password at a later time.

Email sent at registration time does not inform user about privileges what he can do. (Role Assignment happens AFTER email is sent.)

User administration should also happen via the REST API.

If you have sufficient access rights, then you can access the user management GUI using the menu entry "Settings", visible inside the sidebar, the "drawer". After clicking on the user management page (the blue tile in the figure below), you can edit users, groups, and their respective roles. You can also assign specific permissions to these roles.

tiles

mDIS Roles and Permissions

A role represents the function a user has inside the mDIS.

In the tab "Roles" you can see the set of roles already present with their names and description.
You can create as many more roles as you need using the menu button "Create". You can edit or delete a role using the icons in the right column of the table.

roles

Next to the name and description, every role can have children. You can add other roles meaning the role inherits the permissions of these other roles. Additionally you can add explicit permissions (view or edit) for the forms.

Some permission assignments are updated automatically. The role viewer has view access to all forms; the role operator has edit access to all forms. Every time a form is created, updated or deleted these permissions are updated.

Some roles have some implicit permissions:

Only members of role _administrator_ have access to the user management
Members of role developer have access to the template manager

These role names have been chosen to be backwards-compatible with "Legacy DIS", a desktop app.

Users

mDIS Users should be assigned to the roles mentioned above.

Users can log in to the mDIS application using their user name and password. Preferably, every user should have his own account.
In the tab "Users" you can see the list of users. As usual, you can sort the table by clicking on the headers. You can see the user name, the email address and the time of last login into the system.
You can block a user, so he cannot log in any more. With a click on the pencil you can edit the properties of a user.

users

Not shown as a figure here, but easy to get to after clicking on the pencil-icon 📝 on the right of screenshot:

You can edit the email address, user name and password using the tab "Account details".
In the tab "Assignments", you can see and edit his roles (see below) and permissions.
When you click on an empty area in the input field "items", you get a list of all roles and permissions. Permissions can be set for every single data-entry form, if necessary.

::: note Pro Tip: If you have several users with the same permissions, you should create a new role, assign the permissions to the role, and then assign only that one role to these users. This is more flexible and easier to maintain. :::

The "My Account" tile

In the section above, "Login to the mDIS", there was a third tile, "My Account".

Here users can set their own email address and passwords.

Roles and Permissions

Standard Role Hierarchy

_administrator_ - described at the top of this page - can manage user permissions, tables, and forms
developer - can edit forms and tables, create new forms
operator - can edit data, cannot change form and table design
viewer - read only access to full tables
under construction guest - an even less priviledged user who can see only subsets of the data. This can only see datasets labeld as "published", but cannot see data labeled as "embargoed" or "under moratorium" (although these data are physically stored in the same tables).

administrator Roles and Permissions

The role _administrator_ is the most powerful role in mDIS. The administrator role ,as well as the developer role (see below), can define new tables and columns.

And with regard to user management administrator is the only role that can do the following:

the administrator role can define new Frontend users and roles
the administrator role can assign access permissions and privileges to roles
the administrator role can assign users to roles
the administrator role can define file access permissions roles relevant to the upload area

Role 'developer'

A user having the predefined Role developer can interact with mDIS as defined in the PHP dektrium (opens new window) Role-Based-Access-Control (RBAC) User Management library.
The name developer of this role was chosen for backward compatibility with Legacy DIS.
This role implies a user can design forms and customize an mDIS production system, however with less privileges than an mDIS Sysadmin (_administrator_ role). An mDIS developer role, as defined in the MySQL your_mDISdb.auth_assignment table, cannot create new users or change the permissions of other users.
This role also cannot modify tables/models (e.g., add columns).
This role therefore has less privileges than an mDIS Sysadmin (_administrator_ role). An mDIS developer role, as defined in the MySQL your_mDISdb.auth_assignment table, cannot create new users or change the permissions of other users. This role also cannot modify tables/models (e.g., add columns).

Backend / OS Layer

Unixusers and Groups

Linux-centric explanation

This explanation is a bit brief and Linux/Debian-centric. Sorry about that.

With regard to the PHP/ Webserver/Operating System layer, there is no predefined 'administrator' role. There are however the operating system users root (on Unix-based systems) and administrator on Windows-based systems. In Virtualbox, we often use mdis, or vagrant. You choose that name at time of first installation. These OS users have a role equivalent to the sysadmin _administrator_ role in the frontend. They have the sudo role. As "Sudoers" (opens new window) they can (must) do everything inside the host OS and the guest OS, in particular:

installation tasks on the host system and within the VirtualBox guest
seamless rebuilds of predefined forms and tables from within the VirtualBox ('yii migration' tasks)
can upload anything and set OS-related file access permissions relevant to the upload directories

However, managing Linux-users and their access rights is a complex topic that we do not have the space to describe here.

For a deeper dive, see also the developer page.

Even more System Administration

OS-Updates, Email...

See extra document

The document describes optional special-purpose tasks related to working inside mDIS (OS updates, sending email, ...)

List of 3rd-Party Code dependencies

A unified list of references is given at the bottom of the for-developers page.