...
Present DAR UI
Determine if user has RDCA-DAP account.
Download files from RDCA-DAP, using their token exchange service.
Governace UI for creating external access requirement
Rendering the new actions required
Variation: New Aggregating Service
A variation on the design to consider is one which introduces a new back-end service to aggregate information from Synapse and RDCA-DAP. The design discussed above is based on the Portal using Synapse as its back-end, and Synapse acting as a client to RDCA-DAP’s REST APIs:
...
In the alternative, the Portal interacts with a new back-end, which in turn connects to both Synapse and RDCA-DAP. Synapse would not interact with RDCA-DAP at all.
...
The new Server would be an identity federator. Through the Portal it would link the user’s Synapse and RDCA-DAP accounts. When Portal users log in, they would log in to the Server, not to either of the linked systems (though the Server could optionally delegate login to either or both Synapse and RDCA-DAP). The Server would be a proxy for all requests issued by the Portal. The flow for a request to Synapse would be:
Note that when the Portal logins in, it receives an access token to the Service (not for either linked data repository). This is labelled, , “AT-Service”. (The prerequisite account linking is not shown in this diagram.) When the Portal requires a resource which is held by Synapse, it sends a request to the Service, which recognizes the request as being relevant to Synapse, obtains a Synapse access token (“AT-SYN”), issues the request, and returns the result. In short the Service acts a proxy to the Synapse REST APIs. The Service could similarly interact with RDCA-DAP to retrieve resources held there, and perhaps issue data access requests.
Certain Portal requests require more complex business logic in the Service. An example is the Synapse Action Required request for the Download list. The response is a list of {Action, count}, where the Action describes what the user needs to do to obtain access, and the count is the number of files requiring this action. For actions requiring approval in RDCA-DAP, the Server would issue the appropriate request to that system and then update the result to indicate to the Portal whether the action is still outstanding or has been satisfied.
A second example is the Synapse FileStatistics request for the Download List. The response has the fields:
totalNumberOfFiles
numberOfFilesAvailableForDownload
numberOfFilesAvailableForDownloadAndEligibleForPackaging
numberOfFilesRequiringAction
sumOfFileSizesAvailableForDownload
Since some of these values depends on information from RDCA-DAP, the request can’t be handled by simply proxying the service. Rather the Server would have to use the Action Required service (and possibly others) to compute the aggregated result before returning it to the Portal.
A third example is the Synapse Eligible Files request used by the Portal to list the files it can download, a subset of the files added to the Download List. Since Synapse lacks information about whether RDCA-DAP files can be downloaded, the Service would have to compute this list by retrieving the download cart contents and determining eligibility incorporating access approval information from RDCA-DAP. Note the challenges in subselecting data from a paginated list, while maintaining a consistent page size.
A fourth example is the Restriction Information, Batch, service used by the Portal. As with the earlier examples, the Service must query RDCA-DAP for the information about files in the request which it holds. The challenge of building the service is lessened by the fact that it is not paginated. (The request is limited to 50 files.) However, it would likely be replaced with an asynchronous service to reflect the potential delays in relaying requests to multiple systems. The request should also reflect the data contributor bypass feature of Synapse, allowing data contributors to download data without going through a Governance process.
A fifth example is the action required column incorporated in the file view response as invoked in the QueryBundleRequest. As in the Action Required request proxy service, the Service would have to fill in the Action column for external files, noting the challenge in managing a paginated response.
Considerations of introducing a new service
The advantage of this approach is that it creates a clean separation of concerns, in which Synapse doesn’t have to make any requests to RDCA-DAP. While at a high-level the approach would also appear to create a path to disconnecting the Portal from Synapse as a back-end, fully disconnecting them would require reproducing a large number of services on which the Portal depends today, which would be several engineer-years worth of effort. And even the initial implementation would require at a minimum rewriting the five services described above.