Data Layer Access Control

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

Tier 1 Approval Process

Here the user signs the Tier 1 agreement upon account creation and is added to a "Tier 1 group".  The group has the Download role for all Tier 1 data layers.

"WF" refers to an envisioned workflow system which knows the approval workflows and can tell each participant what its next step is.

Tier 2 Approval Process

This approval requires two hurdles, the Tier 1 agreement plus a new agreement which may be specific to the requested layer.  Upon approval Synapse adds the User to the Access Control List for the Layer.

Tier 3 Approval Process

Here we have the added complexity of an external IRB.  An "IRB daemon" is added to send approval requests to the IRB and to listen for replies.  The interaction with the user is asynchronous:  While waiting for approval the user may do other things (though not access the requested layer).  Finally she receives an email saying the request was approved.

Some open questions:

- How does Synapse know not to wait for any more steps, once it gets the final reply from WF (the workflow is not yet done)?

- When Synapse asks "next step" can it refer to a specifc workflow instance (and avoid getting an approval step for some other user)?

New/Modified Synapse Services

Request account (initiates tier 1 workflow as a side effect)

Download access request (initiates tier 2 or tier 2 workflow as a side effect, depending on the layer)

Sign tier 1 agreement

Sign tier 2 agreement

IRB approval of submitted request