Data Access Control

Background

IRB-approved versions of all of the 'data access documents' :

Summary:

- 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. Specifically, the web client has the following logic:
1) When a user tries to download a layer, the Web client checks whether the parent dataset has an associate EULA;
2) If there is an EULA, the web client checks whether there is an Agreement, owned by the User and referencing the dataset and EULA;
3) If there is a EULA but no Agreement, the web client prompts the User to sign the EULA, creates the Agreement, then allows the download.

- There is no provision in our permissions scheme for an "ACT 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 Access and Compliance Team (ACT).

Design

Database

We have two tables, one for ACCESS_REQUIREMENT, with a foreign key to a node (object) and one for  ACCESS_APPROVAL, having foreign keys to ACCESS_REQUIREMENT and principal.  The first imposes a requirement for access to the node.  The second fulfills the requirement, for a given principal. ACCESS_REQUIREMENT has a 'REQUIREMENT_TYPE' field along with a variable 'REQUIREMENT_PARAMETERS' blob, allowing it to be used for Tier 2 or Tier 3 requirements.  (The 'parameters' field could be a Eula, a form to be filled out, or something else.)  The ACCESS_APPROVAL table has an APPROVAL_TYPE and an APPROVAL_PARAMETERS blob, allowing it to be used for Tier 2 or Tier 3 approval.  (The 'parameters' field could be some form contents, user's IRB information, information from the ACT, or something else.)

Below we omit the primary key and foreign key constraints for simplicity.

CREATE TABLE `ACCESS_REQUIREMENT` (
  `ID` bigint(20) NOT NULL,
  `ETAG` bigint(20) NOT NULL,
  `CREATED_BY` bigint(20) NOT NULL,
  `CREATED_ON` bigint(20) NOT NULL,
  `MODIFIED_BY` bigint(20) NOT NULL,
  `MODIFIED_ON` bigint(20) NOT NULL,
  `NODE_ID` bigint(20) NOT NULL,
  `ACCESS_TYPE` varchar(256) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `REQUIREMENT_TYPE` varchar(256) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `REQUIREMENT_PARAMETERS` mediumblob,
 )

CREATE TABLE `ACCESS_APPROVAL` (
  `ID` bigint(20) NOT NULL,
  `ETAG` bigint(20) NOT NULL,
  `CREATED_BY` bigint(20) NOT NULL,
  `CREATED_ON` bigint(20) NOT NULL,
  `MODIFIED_BY` bigint(20) NOT NULL,
  `MODIFIED_ON` bigint(20) NOT NULL,
  `REQUIREMENT_ID` bigint(20) NOT NULL,
  `ACCESSOR_ID`  bigint(20) NOT NULL,
  `APPROVAL_TYPE` varchar(256) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
  `APPROVAL_PARAMETERS` mediumblob
)

Data Access Object (DAO)

We have DAOs for AccessRequirement and AccessApproval objects.  In addition to basic CRUD operations we have:

• AccessRequirementDAO.getForNode(), which returns all the AccessRequirements associated with a Node/Entity
• AccessApprovalDAO.getForAccessRequirementsAndPrincipals() which returns the AccessApprovals for a given list of AccessRequirements and Principals.  This method allows us to look up the approval of all the access requirements for a given node with a single database query.

JSON Schema

We introduce JSON schemas for AccessApproval and AccessRequirement, mirroring the tables above, BUT omitting the variable fields.  This is because the json schema cannot know the a priori the schema of such variable fields, which are managed separately.  We intoduce ENUMs for AccessRequirementType and AccessApprovalType (e.g. ("TOU_Agreement", "ACT_Approval").

We introduce TermsOfUseRequirementParameters to hold the Terms of Use document for an AccessRequirement whose type is TOU_Agreement.

Services

AccessRequirement: Create, Read, Update, Delete

Web UI

TBD