BASE Core specification Access control

Access control

Summary

1. By being the owner of the item.
2. By being a user or member of a group that has been allowed access to the item by it's owner.
3. By being a member of a role that allows access to items of that type.
4. By being a member of a project where the item is used.

1. Access control in BASE always works in the same way, not depending on if internal or external authentication is used.
2. 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.

1. If the item has an owner, the owner always has full access.
2. Items that don't have an owner can only be accessed by role-base permissions (see below).
3. 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.
4. 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).
5. 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.
6. 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.
7. [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:
   1. Check ownership
   2. Check if shared/denied to user
   3. Check if shared/denied to group
   4. Check if shared/denied to role
   5. Check if shared/denied to project
   Some systems has the policy that if a "deny" setting is present, it always wins.

1. 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
2. Roles can be assigned permissions for other system-wide operations not involving any particular item, for example shutting down BASE.

1. Projects are used to gather items of (almost) any type into a single collection.
2. An item has a "project permission" setting that specifies the maximum permission level within the context of the project.
3. An item can be used in zero, one or more projects with different permissions.
4. Users and groups can be members of zero, one or more projects with different permissions.
5. Users and groups can be assigned a generic permission level that applies to all items in the project.
6. 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.
7. A user may select to work with a project. All items created are then automatically added to the project with full permissions.
8. Items can be manually added or removed from projects. The project permission may also be modified.
9. 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.