Changes between Initial Version and Version 1 of AuthModule/RowLevelPermission


Ignore:
Timestamp:
2011-04-30T10:33:38+02:00 (14 years ago)
Author:
Morris Swertz
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AuthModule/RowLevelPermission

    v1 v1  
     1= Row Level Permission design =
     2[[TOC()]]
     3
     4== User story ==
     5As a user I want to specify for each object who is allowed to edit, view, and own (delete, give others permissions)
     6
     7== Requirements ==
     8* The solution should NOT require MOLGENIS designers to change their data model.
     9* It should not be needed to set permission rules on ALL objects but instead permissions must be set to be 'inheritable' between related objects
     10(NB: in MOLGENIS data model we want to specificy these relations as a 'partOf' version of the xref).
     11
     12== Architecture ==
     13A runtime configuration option can be enabled and that 'under water' links an 'permission' system table to 'auth' to set permissions on any object.
     14Big 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.
     15
     16This design has the following components:
     17
     18=== 1. Permission table ===
     19
     20Example fields in this permission table:
     21entityName: xref(MolgenisEntity)
     22entityId: int
     23actor: xref(MolgenisGroup [MolgenisUser extends MolgenisGroup?])
     24permission: {owner, view, edit, execute}
     25unique(entityName,entityId,actor)
     26
     27=== 2. Automatic filtering of any 'row level secured entity' using subselects ===
     28Change the Login class to to inject a QueryRule that has 'subselect' to search permissions and enable filtering in selects and updates. Semicode exle:
     29{{{
     30SELECT ... FROM Investigation WHERE id IN (select entityId from MolgenisPermissions
     31where actor=${currentActor} AND entityName='Investigation' AND permission IN('owner','read','write','execute'))
     32}}}
     33
     34This solution also allows entities to 'inherit' the permissions from a 'parent' object (as long as there is a foreign key path).
     35Semicode example, when ObservationElement would 'inherits' permissions from Investigation:
     36{{{
     37SELECT ... FROM ObservationElement JOIN Investigation WHERE investigation.id IN (select entityId from MolgenisPermissions
     38where actor=${currentActor} AND entityName='Investigation' AND permission IN('owner','read','write','execute'))
     39}}}
     40
     41=== 3. A decorator to automatically set default owner ===
     42At every insert on a 'row level permission' secured entity there must a an appropriate owner be inserted into MolgenisPermissions.
     43
     44=== 4. Sharing user interface ===
     45Generated forms are enhanced with
     46* an additional actionInput where users that are owner can show a 'sharing' dialog (that is a button in both list and edit views)
     47* this sharing dialog lists all permissions for this entity (SELECT ... FROM MolgenisPermission WHERE entityName=%currentEntity% AND entityId=%currentId%)
     48* and allows users to add/remove rules. Minimally one 'owner' should remain.
     49
     50=== 5. Admin user interface ===
     51Extend the security 'admin' user interface where I can tick
     52* which entities should have row level security,
     53* what entities should 'inherit' row level security.
     54* what the default permissions are