Access control in BASE always works in the same way, not depending
on if internal or external authentication is used.
Access control is enforced for all operations in BASE, for example
creating new items, accessing existing items, and other operations
not involving any particular item.
If the item has an owner, the owner always has full access.
Items that don't have an owner can only be accessed by role-base
permissions (see below).
Items that have an owner can be shared to other users and/or groups with
individual permissions assigned to each user/group.
The following permissions levels are defined:
read: the user may read information about the item
use: the user may use the item, ie. reference it from
other items which may include modifying some information
(for example decrease the remaining quantity of a biomaterial)
write: the user may update information about the item
delete: the user may delete the item
set owner: the user may change the owner of the item
set permissions: the user may change which users and groups have access
to the item
[QUESTION] Some permissions are not very useful unless they appear together,
for example "use" implies that a user also has "read" access. Should this be
enforced by the core, or is it up to the client to supply the "correct"
combinations?
Answer: A consistent behaviour is always desired, ie. the core should make those
restrictions.
Users should be able to create a named, predefined set of users and/or groups
with given permissions. We call this set a "key" (hmmm...not very logical in
this context).
While assigning permissions to an item, such a key may be used. If the key is
changed at a later time, the permissions to access the item should reflect
this change.
If a user receives permission from several paths (individually, by group
membership, by role membership or project membership), the permissions are combined.
For example, if a user has individual "read" permission and is a member of a group with
"update" permission the user has both "read" and "update" permission.
[QUESTION] What about a "deny" setting to revoke permissions?
For example, a group is assigned "read" permission, but for one of the members we
want to revoke that permission. On the other hand, how is it decided if "deny"
or "read" permission should win? Another example, a group is assigned "deny"
permission, but we want to give one of the members "read" access.
One solution would be to always let the most specific setting win:
Check ownership
Check if shared/denied to user
Check if shared/denied to group
Check if shared/denied to role
Check if shared/denied to project
Some systems has the policy that if a "deny" setting is present, it always
wins.
Roles are used for assigning permissions to *all* items of a specific type.
Roles cannot be used for assigning permissions to individual items.
The same access levels as specified for users/groups above are used, plus
two new ones:
create: the user may create new items of the specified type
deny: the user may not access or modify any item of the specified type
Roles can be assigned permissions for other system-wide operations
not involving any particular item, for example shutting down BASE.
Projects are used to gather items of (almost) any type into
a single collection.
An item has a "project permission" setting that specifies the maximum
permission level within the context of the project.
An item can be used in zero, one or more projects with different permissions.
Users and groups can be members of zero, one or more projects with different
permissions.
Users and groups can be assigned a generic permission level that applies
to all items in the project.
The permission for a user to access an item via the project is calculated by comparing
the item's project permission with the user's generic permission, and
only allowing actions that are common for both permissions. For example,
a user has "read" and "write" generic permissions to a project, but an
item only has "read" permission. The resulting permission is "read".
Of course, ownership and direct sharing with users/groups also have
to be considered.
A user may select to work with a project. All items created are then
automatically added to the project with full permissions.
Items can be manually added or removed from projects. The project
permission may also be modified.
Adding an item to a project requires at least "use" access to
the item and project. The "project permission"
for the item cannot be set higher than the access permission to the item.