...
The goal of phase one is to expand the permissions of Synapse Governance systems to enable members of the ACT to grant non-ACT users permissions to both review and approve managed access for specific cases. This was identified as both the highest priority change and foundational for other changesItems that are considered out-of-scope for this phase:
Multiple Reviewers - With multiple reviewers for the same AR, there is a potential for various types of conflicts. We will likely need to add add features to prevent or minimize such conflicts sometime in the future. For this phase we will assume that there will be a single reviewer.
Notification Improvements - The extensions document outlines multiple improvements to the notification system around approvals. For this phase we will simply be extending the existing notification system to include the new reviewer.
Delegation of AR creation/update - For this phase, we will only support the the delegation of reviewing access submissions to managed ARs. This phase will not include the support for the delegation of the creation/update of ARs.
Background
Currently, only members of the Access and Compliance Team (ACT) can review and approves data access request. The current authorization system simply rejects any user that is not a member of the ACT when calling the following services:
...
In Synapse we already use Access Control Lists (ACL) to allow one set of users to grant permissions to another set of users on a specific object. For example, assume we want to grant a particular a project owner wants to allow another user permission to add upload files and folders to a specific their project. To do this, an administrator of that project might the project owner would edit the ACL on that project and add an entry that would grant the user permission to “create”. After saving the changes to the ACL, this there other user would then be allowed to add files and folders to that specific project. In this example, the “scope” of the grant is the project.
For phase one, we want to provide a way for members of the ACT to grant non-ACT users permissions to both review and approve AR access requests. A For this case, a natural place to start would be to support the addition of an ACL directly on an AR. The main obstacle to this approach use the AR as the scope of the grant. Specifically, this would involve extending the existing ACL system to allow ACLs to be placed on ARs.
Note: The main obstacle to using the AR as the permission scope is that it cannot be used as a mechanisms to grant permissions to create ARs. However, for at least phase one, only ACT member will be creating ARs, so this seems like a reasonable limitation.
We would then need to change all submission related APIs to perform the following permission check using the AR as the scope:
If the caller is an Admin, then GRANT
If the caller is a member of the ACT, then GRANT
If the caller is anonymous, then DENY
If the caller is has the “REVIEW” permission on the AR, then GRANT
All other cases, then DENY
Note: When a user calls any services that lists multiple submissions, only submission with a GRANT on the corresponding AR will be listed. Submissions with a DENY will be excluded.
This phase will involve the following technical tasks:
Creating/updating ACLs on ARs - This would be a new feature that would allow a member of the ACT to create an ACL on an existing AR. Only a member of the ACT would be allowed to create/update these ACLs. The ACT member would grant a non-ACT user permission, to “REVIEW” submissions to this by updating this ACL. Note: ACT members will automatically retain the “REVIEW” permission for all ARs even if not explicitly listed in the ACL of that AR. Any AR that does not have an ACL will still be fully accessible by members of the ACT.
GET /dataAccessSubmission/openSubmissions - This services would need to be changed to list open submission for any user that has been granted the “REVIEW” permission. Should an ACT member also see listings for submissions to ARs that have granted non-ACT members “REVIEW”?
POST /accessRequirement/{requirementId}/submissions - This service would need to be changed similar to the above.
PUT /dataAccessSubmission/{submissionId} - This service would need to be changed similar to the above.
DELETE /dataAccessSubmission/{submissionId} - This service would need to be changed similar to the above.
...