Row Level Permission design

User story

As a user I want to specify for each object who is allowed to edit, view, and own (delete, give others permissions)

Requirements

• The solution should NOT require MOLGENIS designers to change their data model.
• It should not be needed to set permission rules on ALL objects but instead permissions must be set to be 'inheritable' between related objects

(NB: in MOLGENIS data model we want to specificy these relations as a 'partOf' version of the xref).

Architecture

A runtime configuration option can be enabled and that 'under water' links an 'permission' system table to 'auth' to set permissions on any object. Big advantage is that one doesn't need to change the datamodel. A known drawback is that this table may become very large however as in practice users will not set many permissions.

This design has the following components:

1. Permission table

Example fields in this permission table:

                <entity name="MolgenisPermission" system="true">
                        <field name="id" type="autoid" hidden="true" />
                        <field name="role_" type="xref" xref_field="MolgenisRole.id" xref_label="name"/>
                        <field name="entity" type="xref" xref_field="MolgenisEntity.id" xref_label="className"/>
                        <field name="permission" type="enum" enum_options="[read,write,own]"/>
                        <!-- no use case for 'execute' so don't use it -->
                </entity>

2. Automatic filtering of any 'row level secured entity' using subselects

Change the Login class to to inject a QueryRule? that has 'subselect' to search permissions and enable filtering in selects and updates. Semicode exle:

SELECT ... FROM Investigation WHERE id IN (select entityId from MolgenisPermissions 
where actor=${currentActor} AND entityName='Investigation' AND permission IN('owner','read','write','execute'))

This solution also allows entities to 'inherit' the permissions from a 'parent' object (as long as there is a foreign key path). Semicode example, when ObservationElement? would 'inherits' permissions from Investigation:

SELECT ... FROM ObservationElement JOIN Investigation WHERE investigation.id IN (select entityId from MolgenisPermissions 
where actor=${currentActor} AND entityName='Investigation' AND permission IN('owner','read','write','execute'))

3. A decorator to automatically set default owner

At every insert on a 'row level permission' secured entity there must a an appropriate owner be inserted into MolgenisPermissions?.

4. Sharing user interface

Generated forms are enhanced with

• an additional actionInput where users that are owner can show a 'sharing' dialog (that is a button in both list and edit views)
• this sharing dialog lists all permissions for this entity (SELECT ... FROM MolgenisPermission? WHERE entityName=%currentEntity% AND entityId=%currentId%)
• and allows users to add/remove rules. Minimally one 'owner' should remain.

5. Admin user interface

Extend the security 'admin' user interface where I can tick

• which entities should have row level security,
• what entities should 'inherit' row level security.
• what the default permissions are