User authentication and access control

NOTE! This document is outdated and has been replaced with newer documentation. See The database schema and the Data Layer API

This document covers the details of internal and external user authentication, groups, role and project management, and access control to items.

See also

Last updated: $Date: 2009-04-06 14:52:39 +0200 (mÃ¥, 06 apr 2009) $

Users and passwords

The UserData [API] class holds information about users. We keep the passwords in a separate table and use proxies to avoid loading password data each time a user is loaded to minimize security risks. It is only if the password needs to be changed that the PasswordData [API] object is loaded. The one-to-one mapping between user and password is controlled by the password class, but a cascade attribute on the user class makes sure that the password is deleted when a user is deleted.

Groups, roles and projects

The GroupData [API], RoleData [API] and ProjectData [API] classes holds information about groups, roles and projects respectively. The connection to users are controlled by each of the classes.

Plugins

The PluginDefinitionData [API] class holds information about plugins. If the plugin is defind to use perminssions, the default is to deny everything. The mapping to role key is used to grant/deny permissions to the plugin. See below.

Keys

The KeyData [API] class and it's subclasses ItemKeyData [API], ProjectKeyData [API] and RoleKeyData [API], are used to store information about access permissions to items. To get permission to manipulate an item a user must have access to a key giving that permission. There are three types of keys:

Type	Description
1	Item key: Is used to give a user or group access to a specific item. Such an item must be shareable, and the permission for other users/groups are set by the owner of the item. Once created an item key cannot be changed. This allows the core to reuse a key if the permissions match exactly, ie. for a given set of users/groups/permissions there can be only one item key object.
2	Project key: Is used to give members of a project access to a specific item. The item must be shareable. Once created a project key cannot be changed. This allows the core to reuse a key if the permissions match exactly, ie. for a given set of projects/permissions there can be only one project key object.
3	Role key: Is used to give a user access to all items of a specific type, ie. READ all SAMPLES. The installation will make sure that there already exists a role key for each type of item, and it is not possible to add new or delete existing keys. Unlike the other two types this key can be modified. A role key is also used to assign permissions to plugins. If a plugin has been specified to use permissions the default is to deny everything. The mapping to the role key is used to grant permissions to the plugin. The `granted` value gives the plugin access to all items of the linked item type regardless if the user that is running the plugin has the permission or not. The `denied` denies access to all items of the linked item type even if the logged in user has the permission. Permissions that are not granted nor denied are checked against the logged in users regular permissions. Permissions to items that are not linked are always denied.

Permissions

The permission column appearing in many tables is a code describing the permission:

Value	Permission
1	READ
3	USE
7	RESTRICTED_WRITE
15	WRITE
31	DELETE
47 (32+15)	SET OWNER
79 (64+15)	SET PERMISSION
128	CREATE
256	DENIED

The values are constructed so that READ-USE-RESTRICTED_WRITE-WRITE-DELETE are chained in the sense that a higher permission always implies the lower permissions also. The SET OWNER and SET PERMISSION both implies WRITE permission. The DENIED permission is only valid for role keys, and if specified it overrides all other permissions.

When combining permission for a single item the permission codes for the different paths are OR-ed together. For example a user has a role key with READ permission for SAMPLES, but also an item key with USE permission for a specific sample. Of course, the resulting permission for that sample is USE.

If the user is also a member of a project which has WRITE permission for the same sample, the user will have WRITE permission when working with that project.

The RESTRICTED_WRITE permission is in most cases the same as the WRITE permission, and it is only meaningful to assign WRITE permission. So far the RESTRICTED_WRITE permission is only given to users to their own UserData object so they can change their address and other contact information, but not quota, expiration date and other administrative information.