This section gives an overview of user authentication and how groups, roles and projects are used for access control to items.
The UserData
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
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.
The GroupData
,
RoleData
and
ProjectData
classes holds
information about groups, roles
and projects respectively. A user may be a member of any number of groups,
roles and/or projects. New users are automatically added as members of all
groups and roles that has the default
property set.
The membership in a project comes with an attached
permission values. This is the highest permission the user has in the
project. No matter what permission an item has been shared with the
user will not get higher permission. Groups may be members of other groups and
also in projects. A PermissionTemplateData
is just a holder for permissions that users can use when sharing items. The
template is never part of the actual permission control mechanism.
Group membership is always accounted for, but the core only allows
one project at a time to be use, this is the active project.
When a project is active new items that are created are automatically
shared according to the settings for the project. There are two cases.
If the project has a permission template, the new item is given the same
permissions as the template has. If the project doesn't have a permission
template, the new item is shared to the active project with the permission
given by the autoPermission
property. Note that in the
first case the new item may or may not be shared to the active project
depending on if the template is shared to the project or not.
Note that the permission template is only used (by the core) when creating new items. The permissions held by the template are copied and when the new item has been saved to the database there is no longer any reference back to the template that was used to create it. This means that changes to the template does not affect already existing items and that the template can be deleted without problems.
The KeyData
class and it's subclasses
ItemKeyData
, ProjectKeyData
and
RoleKeyData
, 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:
ItemKey
Is used to give a user or group access to a specific item. The item
must be a ShareableData
item.
The permissions are usually 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.
ProjectKey
Is used to give members of a project access to a specific item. The item
must be a ShareableData
item. 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.
RoleKey
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 plug-ins. If a plug-in 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 related item type regardless of if the user that is running the plug-in has the
permission or not. The denied
values denies access to all
items of the related 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.
The permission
property appearing in many classes is an
integer values 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 permissions |
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
. For other samples the resulting permission is
READ
.
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. 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.