Background
- Data layer access in Synapse requires one or more approval steps.
- In Synapse granting data access is synonymous with providing the URL to the stored data.
(This URL may have an embedded access token.)
- Currently (i.e. as of Jan. 2012), the backend has a representation of EULAs and of Agreements (i.e. that a particular user agrees to a EULA)
- The work flow logic for creating the agreement is embedded in the Web client, so other clients would have to maintain duplicate logic.
- There is no provision in our permissions scheme for an "IRB role" which can grant or revoke 'download permission' to a user.
- If the approval process changes, a user who has already been approved needs to go through the approval process again.
- Currently we've identified three tiers of access restriction/approval:
Tier 1: User agrees to a generic EULA that applies to all data layers available through Synapse.
Tier 2: (Tier 1) + User agrees to a second EULA specific to certain data layers.
Tier 3: (Tier 1) + (Tier 2) + User access must be requested/approved through an institutional review board (IRB).
Straw man design
Security Model
- A "role" is a collection of permissions. E>g. if the available permissions for an entity are Create, Read, Update and Delete, there might be an Editor role which includes Read and Update. To meet the data layer access requirements we propose to extend the current permission scheme:
1) Instead of defining permissions on an entity, we define permissions on a property within an entity;
2) Instead of granting individual permissions on an entity to a principal, we grant a role to a principal
So instead of ACL=<Entity, {<Principal, AccessType>}> (where "{}" indicates a set and "<>" a tuple) we have ACL= <Entity, {<Principal, Role>}> where Role={<Property, AccessType>}. (Q: Is a 'role' entity specific? How do we grant access to non-property aspects of an entity?)
Under this model we can separately grant read access to a layer's basic properties (name, created date, description) and its location. Read access to a layer's location is the equivalent of download access.
Note: This 'enhanced' security model can be used in advance of creating services for defining roles: We can define the currently required roles 'in the backend' and later add services and UIs for defining new roles.
Workflow Model
Should the approval process be represented on the server side (e.g. in the repository)?
How does *approval state* map to *permissions*?