Access to an item can be granted by four different ways:
The final access permission is given by the combined permission of the four
- By being the owner of the item.
- By being a user or member of a group that has been allowed access to the item
by it's owner.
- By being a member of a role that allows access to items of that type.
- By being a member of a project where the item is used.
1. Access control
- 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.
2. Access to items
- 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"
Answer: A consistent behaviour is always desired, ie. the core should make those
- 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
- 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
- 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:
Some systems has the policy that if a "deny" setting is present, it always
- 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
3. Role-based access to items
- 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.
4. Project-based access to items
- 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
- 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.