EMMAWiki/TermsAndConcepts/ForUsers/Access Control

Access Control

Access control in EMMA 2.0 is provided for each individual object. You may check and change other member's rights on experiments and data you have created. The access control model in EMMA is two-fold. It consists of the two basic components:

• Role-based access control -- Defines global privileges for a specific project.
• Access control by privileges -- Defines per-object (experiment, data) access

Role-based access control

To understand, how role-based access control works in emma, we have to look at the following concepts:

• User
• Member
• Role
• Right

These concepts are common for all software packages using the GPMS.

User

A user is somebody with an account - login name and password and email address - in the GPMS. The user is registered, but does not need allowed to access a single project.

Member

The Member is a User, having access to a specific project. Membership can be granted by a Chief of that project. A user can be a member in many projects.

Rights

A definition of what somebody could be allowed to do in a project. E.g. delete a dataset or import data. There are many rights defined for EMMA. If you do not have the right to perform an action, the system will not allow you to do it.

Role

A collections of individual rights for a project. Many users may share a single role, and a role will comprise many rights. E.g. The User may import data, create experiments, but not edit the standard pipelines or the array layouts. The role of a member may vary between different projects.

• For each project, there is a "chief" who has all the privileges and can give access or not to other users for this project. He also decides what kind of tasks you can perform or not on this project, e.g. to change an existing pipeline or to create a new one.

Here are the different types of roles you can have in a project and their corresponding privileges.

• Admin -- A root-like role. The initial administrator who created the database and project and inaugurates the Chief, and thus has unrestricted access to all data anyway. This role should never be given to somebody else.

 Note: A Chief will not be able to give the role Admin to a member, only the Admin himself.

• Chief -- The main responsible, may add, edit and delete almost everything, including array layouts and pipelines. May add and remove members of a project.
• Maintainer -- Same as Chief, but may not manage memberships.
• User -- May import data, run pipelines, create new experiments.
• Guest -- May do almost nothing, just look. Even viewing things can be restricted.

The majority of users will have the role User. This role is sufficient to do the work, while other roles allow to change the setup of the project

The role of a member may vary between different projects. You could be Chief in your own project, but guest in projects of other groups.

Access control by permissions

GPMS roles define global rights on a project, e.g. if you are allowed to add users or delete something at all. But what if you want to give access to the experiment you created to somebody else? The GPMS does not know of any data in the project, that will be empty in the beginning. Here, the permissions system comes in.

The permissions system provides a fixed set of permissions on an object (e.g. Experiment) to a user or a group of users.

• only members of the current project can aquire permissions.
• many groups of users may be created by the Chief for each project. A user may belong to none, one or many of them.

The permissions apply only for the actual combination user and object. So other users may have other permissions on this object and the same user may have different permissions on every object. Every individual user or group can have either zero or one set of permissions per object.

• The owner is a special kind of user, normally the person who created an Experiment. The owner starts out with a default permission set, alowing every action on a given object. Ownership may be changed only by roles Chief and higher.

The permission set consists of the following fixed actions:

• Read -- The user may look at the object, view the information provided, like name, descriptions, individual data, etc.
• Edit -- The user may change values, names, descriptions.
• Reference -- The user may use this object (mostly important for arrays and array layouts) for his/her own purposes. A array maybe re-used in another experiment, for instance.
• Delete -- What it says: may remove the object permanently.
• View permissions -- The user may view, which permissions were given to this object.
• Change permissions -- The user may alter the permission settings

Each permission can be set to one out of three values:

• Yes -- Grants the permission.
• No -- Forbid the action ultimately, never allow the user to perform it
• Undefined -- Does not grant the permission, means don't care

The permission system has a 'deny-by-default' rule. Means: if noone gave you permissions, you do not have them (frankly: Everything not allowed, is forbidden ;-) ). A user has to aquire a Yes somewhere, by user or group permissions, to deal with an object.

What is the difference between Undefined and No: A user may have a user permission A and be member in a group having permission B. This could confuse the permissions. Thus, No always wins over Yes. The operation, to figure out the actual permissions can be seen of a logical AND operation on the user's permission and all the user's groups.

Examples:

• Joe User is member of group Guests. The permissions for a Experiment say Joe User: delete=Yes and Guests: delete=No. So, although Joe User has a permission to delete, the Guests No strikes and so Joe User may not delete this Experiment.
• Jane User is member of group Users. The permissions for a Experiment say Jane User: delete=Yes and Users: delete=Undefined. 'Undefined' is simply ignored, and Jane got one Yes, so she is allowed to delete the Experiment.

Warnings:

 /!\ Use of No can have bad effects. You can lock yourself out from an object, even your own. Be carefull to set group permissions to No. Maybe you are a member of that group?

 /!\ Be careful with Change permisions. If you set it to No for yourself, you will not be able to set it back. If you set it to Yes for another user, this person may alter the permissions at will. Normally this should be left Undefined except for the owner.

Remarks on permissions

• The permissions only account for roles User and lower. Chiefs, Maintainers and Admins just override all of these settings. This is mainly for cleaning up the mess, the users will create ;-)
• Not having permission read also means that you do not notice the object even exists. It will never be visible in lists.
• There are several combinations of permissions which do not make sense. If you do not have the read permission, you will nver be able to change something, as you do never see it.
• The special group ALL can be defined in all projects. All members of the project are automatically members of ALL. If you want to make an experiment visible to everyone, set read permission for ALL group.
• If youwant to set an object to immutable, to prevent accidential deletion, set the delete permission for ALL to No. If you later change your mind, you can set the permission back.
• Permissions do not automatically account for Arrays and Data in Experiments. They have to be set explicitly.
• When a member is removed from a project, the permissions are not automatically removed. Also the ownership of the Experiments the user has created remains. This serves to track, who created what. The former member will not have the possibility to see his objects as he cannot log in. If necessaray the ownership of the old objects can be changed by the Chief. If later the member is added again, the permissions will apply again.