AMPALS Portal - DAR and Approval Integration
Introduction
The ALS Knowledge Portal aggregates content from multiple data repositories, enabling researchers to browse, search, query, and select data from multiple platforms for analysis.
Currently, users who want to access data hosted by the Critical Path Institute must submit a data access request through https://fair.dap.c-path.org. After a request is submitted, the ALS Knowledge Portal calls the FAIR API to check the request approval status. Once approved, the user signs in to RDCA-DAP and accesses the data through their approved workspace.
Purpose
The purpose of this design is to improve the user experience by allowing users to create data access requests directly from the ALS Knowledge Portal instead of signing in to RDCA-DAP. The ALS Knowledge Portal will display the request status. Once a request is approved, users will go to RDCA-DAP to download or query their approved data within the approved workspace.
Data
The C-Path datasets displayed on the ALS Knowledge Portal are governed by a contractual agreement with the Critical Path Institute. Any modifications—such as adding or removing datasets—would require changes to this contract. Currently, only 5 RDCA-DAP datasets are listed on the Portal, and users can submit data access requests exclusively for these 5 datasets.
Recommended Approach
Users may submit multiple Data Access Requests (DARs) for C-Path datasets. In the initial release, the ALS Knowledge Portal will display the status of the user's most recent DAR for a given dataset; users can visit RDCA-DAP directly to view their full DAR history. Once a DAR is approved, the user must log in to RDCA-DAP to analyze the data in their approved workspace.
This introduces a new feature for tracking DARs submitted to third-party systems that host restricted data outside of Synapse. FAIR serves as the source of truth for form definitions and DAR status; Portal will handles token exchange, aggregation and response shaping.
Eligibility:
A user is eligible to submit a DAR if they have linked their ALS Knowledge Portal account with RDCA-DAP. In practice, this means the user must have logged in to RDCA-DAP at least once prior to creating a DAR.
Form Steps & Grouping Strategy
Tabs: Destination (choose dictionaries + choose/create workspace) → Workspace (only if creating a new one) → Project → About → Complete (accept terms). Form data is loaded lazily per step (NOT one bootstrap) because a user may linger on Destination, never create a workspace, or abandon the flow.
High level Design Diagram
Major Security Concern: Access Requirement (AR) Coupling
The current design attempts to map C-Path external approval status directly to a local Synapse
AccessRequirement(AR). Because Synapse relies on a backend service account token exchange rather than OAuth/identity federation, Synapse cannot cryptographically verify that SynapseUser Ais authorized to submit requests on behalf of RDCA-DAPUser B.Security Vulnerability
If a malicious user submits false identity details in the static DAR form, C-Path’s resulting approval will cause Synapse to set
hasUnmetAccessRequirement = false. This creates a severe security vulnerability where an unauthorized user can unlock and access Synapse-hosted data gated under that same AR within Synapse—completely bypassing Synapse's access control boundaries.Recommendation
We should decouple C-Path external request tracking from Synapse’s internal
AccessRequirementengine, or require a one-time OAuth identity linking step with RDCA-DAP before allowing DAR submission.