Project Access Control

Each project contains an Access Control List (ACL), representing the consumers that can access its content.

Consumers are actually other projects that request (through a user) to access their content. This enables a permission-by-delegation mechanism for which a project can automatically grant access to its content to users logged on another project, providing that this second project has been allowed to access the content of the first.

Typical use cases for the ACL are all those functionalities related to alignment. If two datasets are both available on the same VB instance, it would be very convenient to allow access to each other (or just from one to the other) in order to perform alignments between them, benefiting from the direct access to the resources available in the two projects.

Another case is related to proper rendering of entities present in a foreign dataset. If a project A contains mentions of entities present in an ontology present in project B, having A granted access to B enables for a more efficient rendering of the resources in B when shown in A, instead of looking for their descriptions on the Web.

Access Control List

Formally, the ACL it consists of two elements:

The ACL list itself, containing entries in the form of <ProjectConsumer, AccessLevel> pairs
a "lockable" property, telling if the project containing this ACL, can be locked for use by a ProjectConsumer, and with which modality

The AccessLevel can have two values: R (read), or RW (read/write). This tells if the project content can be accessed (R or RW) by the paired consumer, and if the consumer may also edit this content (RW). The sole presence of a ProjectConsumer in a Project's ACL thus enables that consumer to access the project's content.

Locking works in a different way from traditional locks (actually, its values have to be read the opposite way: we were tempted to give it a different name, though we ended up deciding that, whichever way it is managed, it still represent a lock!). Traditional locks are usually activated by a controller (e.g. an Operating System) whenever an agent tries to access a resource (e.g. a file) managed by it. The way in which the resource is being used by the agent automatically implies the kind of lock set on it. For instance, a read-write operation on a file, implies the file cannot be accessed, because its content is subject to change. However, projects contain large non-atomic data repositories which can be potentially accessed in parallel by different actors. Atomic operations are in any case guaranteed to not overlap with each other by means of ACID transactions, and this is independent of the consumer (two users could make an attempt to touch the same data even from the same consumer). Thus, the LockLevel is more concerned with establishing a level of global exclusiveness on the access to a project, for a certain consumer.

The LockLevel associated to each project, and reported in its ProjectACL, can assume the following values:

NO: the project cannot be locked by any consumer
W: the project can be locked by a consumer so that its content cannot be modified by other consumers
R: the project can be locked by a consumer so that its content cannot be accessed at all by other consumers

Thus, this form of locking describes not the kind of access which is being currently done on the resource (in fact, there could be more consumers accessing in parallel, with different levels, the same project), but the kind of access which is being forbidden by a single consumer asking for exclusiveness on that same form of access. As a consequence, R is the strongest form of lock, as it prevents other consumers from doing READ operations (and, implicitly, even WRITE ones).

Online Access Status

The Access Control List describes the access allowances established for each project in a given VocBench instance. These reflect the possibilities for various consumers to access each project. The Online Access Status represents instead the actual list of consumers which requested access to the project in the current running system.

Access requests are evaluated by both considering the ACL and the online status of a project. The ProjectManager keeps track of the status of all projects, telling whether they are open, which consumers are accessing them and with which AccessLevel, and if a Lock has been set on them. Whenever an access request to a given project comes from a consumer, the ProjectManager performs a series of checks, by first analysing static compatibility of the consumer with the ACL of the project to which access is requested, and then examining if the online status of the project (alone, or combined with the ACL) forbids the request.

When a project is created:

its ACL, unless differently specified, is set to SYSTEM, RW
it is also automatically accessed by its consumer in RW mode and with NO lock on it.

This way, a project created through SYSTEM, initially can only be directly accessed by users in read/write mode (SYSTEM consumer RW mode), but their data cannot be inspected by other projects in turn. NO lock is active on it, though this option is useless until a new consumer is added to the ACL (as only SYSTEM can access its content)

Configuring the Project Access Control through VocBench UI

The Project Access can be configured through VocBench by clicking on the ACL button at the top-rightmost part of the Projects page.

Once clicked, a matrix for the ACL is shown on the screen (figure below). The column on the left lists the projects available in VocBench, while the header for the rows lists the consumers (other projects trying to access the content of the project in the row).

SYSTEM is a special consumer, representing users logged to the project itself (with no intermediation from another project).

Each cell crossing a project with a consumer, describes the kind of access granted to the consumer by the project and it is colored with a green background if the consumer accesses the project (e.g. in the screenshot below SYSTEM accesses foaf project).

Each square is in any case explained by a tooltip, which specifically indicates the involved resources, for example hovering the green square crossing SYSTEM-foaf pair, a tooltip will show the message:

 Available Access Level: Project 'foaf' grants Read and Write access to 'SYSTEM'

  Acquired Access Level: Project 'foaf' is accessed by 'SYSTEM' in Read and Write level

By clicking on the "pencil" symbol besides each project, it is possible to edit its specific ACL. In this case, after clicking on the foaf project, a list of consumers, including SYSTEM plus all the other projects in the VB instance is shown. For each consumer, it is possible to state the possible level of access. By default it is RW for SYSTEM (otherwise users logged to the project would not even be able to write its content) and not defined for the other projects.

The lockable value determines, univocally for all consumers, if these can access the given project and lock it for R or RW.

A universal access level can be stated, namely the Access Level that the project will grant to all the other projects, thus avoiding the admin to update the level to every single project but simply update them all in a single shot.

In addition to the access levels we already seen, R and RW, a special EXT level is available for this option. By setting universal access level to EXT in a project P, each user that can access project P (having a role assigned in it) can also reach P from a second project P¹ even if P did not explicitly granted access to P¹ through the ACL.

The lock level is shown for each project in the square beside the "pencil" button. In case the project is locked, as well as for the access level, the square is colored with a red background.