DACO role management proposal

[kcranston]

First draft of a DACO role management proposal that (once implemented) will address Pan-Canadian-Genome-Library/pcgl-authz#80

Pinging @joneubank @lindaxiang @edsu7 @leoraba for feedback, as this affects DACO and Submission.

[daisieh]

I think this tracks with what we agreed on.

[daisieh]

The POST could include the study id in the body of the request, along with start and end dates, instead of having it in the url.

[leoraba]

Some questions about this:
First, is this going to be a new endpoint? if yes,

1. what is <id> in this endpoint? email or PCGLID?
2. what would be the API to remove dac authorizations.

Currently as per authz docs there are 2 endpoints to grant DAC authorizations and 1 to delete

• POST /study/{studyId} - body: email address, start/end date.
• POST /user/{userId} - body: studyId, start/end date
• DELETE /user{userId}/study/{studyId}

these endpoints are very useful from DACO, would be a chance to reuse those? allowing only if bearer token belongs to a DAC chair of that specific study?

[daisieh]

Those are the endpoints we're talking about, but I think that we'd change the user POST to include /access_approval to make it more clear that it is only the user's access to a study that is being changed.

[kcranston]

I do think that having a specific access_approval makes it clearer what the DACO roles can do (editing the study_id for a user is less clear). And changing it now seems preferable than a breaking change after launch. Is that acceptable?

[leoraba]

i agree POST /user/{userId} is not clear enough, may I suggest maybe POST /user/{userId}/dac_authorizations so it's clear it's dac authorizations, and not study authorizations

[joneubank]

The proposed added endpoint is fine, but it doesn't fit into the operation of DACO application very well. We require information about DACO memberships of a user upfront, not checked on a per study basis.

In addition, I have called out the specific rule that needs to be enforced when a user is being granted DACO access to a study. I think this rule needs to be made very clear:

When a user (applicant) is being granted DACO approval to have read access for a study, it is required that the request be made by a user that is a CHAIR of the DAC which is associated with that study. Studies without a DAC cannot have users granted DACO approval.

[joneubank]

Documentation states two different paths for this action.

[joneubank]

When should DACO call this endpoint. What behaviour does this action provide?

Is this to:

• check if a user is a DACO chair and may approve an appliciation?
• assign a user DACO approved read permissions for a study?

[kcranston]

intended for the former (check if the user is allowed to approve applications). If DACO is determining roles with the user endpoint and using that info to determine what UI actions are provided, then perhaps all we need in auth is an authorization check on incoming /user/<id>/access_approval/<study_id>.

[joneubank]

When a user logs in, DACO application requires to know:

• if the user is a member or chair of a DAC
• which DAC they are a member or chair of

This enables the API and UI to provide the right information for the user to see applications made to that DAC.

We have been getting this information through the /user/me endpoint and parsing their group membership. From this we determine:

• which DACs they are a member of
• which DACs they are the chair of
  Both those values are lists of DACs, though we don't expect multiple membership it is possible based on user assignment to comanage groups.

DACO application also maintains a mapping of Studies to their DACs, as this is required when a user is applying to multiple studies in a single application. The API and UI both have functionality to restrict the application to only include studies managed by the same DAC. Note that the user is not necessarily aware of what DACs exist or how the studies of interest map to a DAC, so there is no "select DAC to apply to" process, this is managed through the study selection step in the application.

What this all means is that:

• DACO application needs to know the user DAC memberships to function fully
• DACO application needs to look up this membership by user ID, not by study or DAC ID.

[daisieh]

DACO application also maintains a mapping of Studies to their DACs, as this is required when a user is applying to multiple studies in a single application. The API and UI both have functionality to restrict the application to only include studies managed by the same DAC. Note that the user is not necessarily aware of what DACs exist or how the studies of interest map to a DAC, so there is no "select DAC to apply to" process, this is managed through the study selection step in the application.

I don't think that the researcher-user-applicant (what should this person be called, to distinguish from the DAC member/chair users?) has any need to access authz, do they? What does this interface look like, from the user perspective?

[joneubank]

As I interpret this section, it is meant to describe the process by which DACs will be setup? Like the human processes for managing that data? I think this is a bit more useful info hre:

How DACs will be Managed

• DACs are registered in the Submission Service, this is where their DAC ID is defined. This is the same database where studies are registered and submitted data is tracked to. It holds the official relationship for Study->DAC.
• Each DAC will have two COManage groups created for the Chair and Members (PCGL:DACO:Chair:{dac_id}, PCGL:DACO:Member:{dac_id})
• Studies registered in AuthZ can be provided a DAC ID. Some studies will be registered before being assigned a DAC. This allows data submission to happen before a DAC has been selected. Studies need to be able to be updated with a DAC ID after being first created.
• When a user (applicant) is being granted DACO approval to have read access for a study, it is required that the request be made by a user that is a CHAIR of the DAC which is associated with that study. Studies without a DAC cannot have users granted DACO approval.

Two things to resolve here:

1. First Bullet - with this proposed plan, there are two sources of truth for the study->DAC mapping (Submission Service and AuthZ). It would be best if this data flowed automatically from a single source of truth into the other services. Right now, all the Study and DAC registration is happening in the submission service, and then is manually duplicated into AuthZ. We need to find a system to connect these data sources to prevent human copy/paste type errors.
2. Last Bullet - this is the primary rule that we want to enforce for DACO users: restrict the users that allow assigning permissions. It maybe should be bolded and centred and highlighted and made very obvious, not at the end of this list.

[kcranston]

re: study-DAC mapping, it sounds like we potentially have this information in triplicate (Submission = source of truth, then duplicated in DACO and authz). If we want a single source of truth, then we need an API call in the Submission service that allows us to interrogate this relationship, and both DACO and auth would call that whenever they need to know.

[kcranston]

I editing the intro and moved up the primary rule to the top

[kcranston]

We probably want to track these identified challenges in other places (submission? research portal?):

• the ability to create an Study and submit data without defining the DAC leaves open the possibility that a user could attempt to submit a data access request for a Study that has no associated DAC. Ideally, the DAC would become required at some point of the submission process.
• the study_id <-> dac_id associated is being stored in three different places - the Submission service (the point of truth), the DACO Portal and Authz. We should either 1) store it in only the Submission service and provide an API call for other services to interrogate the relationship; or 2) ensure that caches in DACO / authz get updated when the data in Submission changes

[daisieh]

Not sure where to put this, but I think that the simplest model would be to use only the study-based endpoints:

• POST /study/study_id/dac_authorizations adds authorizations to a study, only allowed for the study's DAC chair
• DELETE /study/study_id/dac_authorizations revokes authorizations, only allowed for the study's DAC chair
• GET /study/study_id/dac_authorizations lists them, only allowed for the study's DAC chair and members

and remove:

• POST /study/study_id: this is a renaming to /study/study_id/dac_authorizations
• POST /user/{pcgl_id}: this can be reframed as POST /study/study_id/dac_authorizations
• GET /user/{pcgl_id}/study/{study_id}: this can be reframed as a call to /allowed
• DELETE /user/{pcgl_id}/study/{study_id}: this can be reframed as DELETE /study/study_id/dac_authorizations