Access Control Model

As stated in section 5.3.1, providing a secure level of access control is essential for data privacy and thereby acceptance of the software system. A software component providing access control has to be integrated into the described framework. An access control component has to fulfill two authorization tasks. First, access to the individual repository or project has to be controlled, and second, access to each individual object of interest within this repository has to be controlled on a per-user

basis. Additionally, it should be possible to restrict the available functionality for each user in such a way that users can be excluded from performing computationally intensive or possibly dangerous tasks, for example deleting objects or adding new functionality.

A role-based approach was chosen to accomplish this tasks. As such it has several advantages over a simple per-user approach. While providing a high level of granularity to control access, it also keeps the system manageable by providing sets of predefined access rights for objects. A role provides a set of rights within the domain. By defining a role of a user, the possible actions a user can perform within a system are defined.

A primary problem with role-based access control systems is the dynamic nature of the objects. Objects may be created, modified and destroyed during normal operation of the system. In order to keep up with the dynamics of the changing repository, either the access rights of every role would have to be constantly up- dated or could only work on classes of objects and not on individual instances. Both approaches seem rather unsatisfying, as the former makes the role contents unpredictable and involves a large management overhead, and the latter does not fulfill the requirements.

Access control lists provide a convenient way of customizing the access rights of individual users on a specific object. Thus it was decided to expand the role-based approach by adding user and group-based access control lists (ACL) to the system. The ACLs provide the ability to specify access rights for individual objects in the repository. Users can be organized into intersecting groups, having their own ACLs. As a user can be assigned to only a single role within the role-based access model, this concept helps to organize access rights within large projects.

It is necessary to define the set of access permissions controlled by the ACLs. The permission set consists of the following actions:

Read The user may look at the object and view the information provided, like name, descriptions, individual data, etc.

Edit The user may change values, names and descriptions.

Reference The user may re-use this object (mostly important for arrays and array layouts) and link to it. For example, an array can be referenced in another experiment.

Delete The user may remove the object permanently.

View permissions The user may view the ACLs assigned to this object.

Change permissions The user may alter the permission settings by adding and removing ACLs.

6.2. Object Model 93

ACL

- read : bool = FALSE - edit : bool = FALSE - delete : bool = FALSE - reference : bool = FALSE - view permissions : bool = FALSE - change permissions : bool = FALSE

+ check_acl(operation : string, user : User, object : MAGE-Object) : bool

GroupACL UserACL MAGE-Object User + login : string + name : string Group + name : string

There can exist only 0..1 UserACL and GoupACL per unique combination of User and Object or Group and Object. Object Group User Owner Membership +memberOf

Figure 6.2: Simplified UML-model of the database classes representing the access

control system. The user and group ACL classes represent the access control lists for users and groups of users and are both derived from the ACL superclass. The ACL class can control access to any object within the MAGE-OM.

Yes Grant the permission, equivalent to a logical TRUE value.

No Forbid the action, never allow to perform it, equivalent to a logical FALSE value.

Undefined Do not grant or forbid the action, ignore this setting equivalent to a logical missing value.

A combination of all permissions with an assigned value, a user or group, and an object constitutes a complete ACL. The resulting permission is derived from a combination of all ACLs assigned to the user for the given object; ACLs can be either directly assigned to a user or assigned by group memberships. As a result, many ACLs may apply for a given combination of user and object. In case of a conflict, the permissions are computed from all ACLs using a logical AND operation. Undefined values are simply ignored; if there are only undefined values the default access policy is used.

The default access policy needs to be defined for each action in the action set. If the permission settings for an action consist only of missing values or if there are no applicable ACLs, the default ACL is substituted. For reasons of data security, without a specific default policy, a deny-by-default policy is applied. This results in an often desired behavior where a user cannot perform any action until it is explicitly allowed.