Determine permissions needed to provide secure access to Sonador resources: create test/validation plan documents and trace matrix

IMPORTANT: Refer to the following for details on ACL and grant systems.

Reference issues and merge requests:

• Tracking issue: oak-tree/medical-imaging/sonador#53. Provides detail about development tasks (some of which are not yet tracked by issues), design notes, URL endpoints, and high-level test cases. Comments also provide important details about implementation progress and change history.
• Technical notebook: describes reference implementation, engineering notes for server API, and demonstration of Sonador IO client API methods
• Testing and validation plans Documentation Issue #55 @hans.deraad
• Testing matrix covering roles, permissions, and test cases Documentation Issue #55 @hans.deraad
• Global Permissions Ftests Implementation Issue #56 @akimbotwix
• Local Permissions Ftests Implementation Issue #57 @akimbotwix

Requirements:

• Implement a permissions structure in Sonador so that Orthanc can determine from a user, URL, and (maybe) additional information whether a user should be granted access to a patient, study, or instance.
• Make OHIF aware of user permissions so that is able to hide/show features based on the role of the user
• Allow for the permission system to be sufficiently flexible so that it is possible to allow for sharing of resources, but still enforce multi-tenancy requirements. (Refer to use-cases for additional detail.)
• Permissions are defined in the "Image Servers" interface in Orthanc and are associated with a group. Users are inherit their access to image servers via group membership.
  • Multiple group permissions can be associated with a single server and users can be part of multiple groups.
  • When an authorization request is made to Sonador, the application will inspect all granted permissions and select the most appropriate.
• Authorization requests will work via the "filter" hook in the Sonador Plugin (refer to orthanc-sonador#2 (closed)) and will extend the authorization forms/views already present to include additional functionality. Updates to the authorization system available in Orthanc allow for the incorporation of a user-profile and overriding application-level endpoints will allow for multi-tenancy scoping. These two developments alleviate the need to implement a separate filter function.
• The existing (pre 0.3) authorization system in Sonador (which is based on the advanced authorization plugin) will also be preserved as an option so that versions of Orthanc prior to 1.11.1 will still be supported. The new advanced authorization plugin features are "in addition" to the token validation that occurs in Sonador > 0.3.
• Filtering of studies based on permissions is performed using the Sonador Resource Cache. This will require the replacement of /tools/find with requests that are scoped by an authorization grant.

Use-cases:

• Multi-tenancy. Allow multiple organizations access to a single Orthanc server in a secure fashion. Prevent organization A from being able to see or access the resources of Organization B without permission.
• Resource sharing. Allow an authorized user from organization A to create a "sharing link" or "access control list" which allows for organization B to view assets.
• Global Find. Provide a permission so that a user (or an API integration) can access all resources stored in the server.

Example frontend (OHIF) views:

• My Patients
• "Care Team Patients". Patients which have been shared with another organization.

"My Patients" view in Quentry.

"Care Team Patients" view in Quentry.

Existing permissions interface in Sonador backend. Should be extended to support additional authorization features described in this issue.

Project Tracking

OP#75 OP#134 OP#135