[Sync Enhancement | Data Access Checker] Identify the App & User assignments for the User requesting the data from the server

[dubdabasoduba]

Context

• The Authentication, Authorization & Data filter on the Proxy Server will need to identify the app and user requesting the data from the server.
• This will enable the identification of the user assignments and the syncStrategy to sync data from the server to the FHIR Core application.

Description of enhancement

• Fetch the Application ID from the Authorization token in the HTTP request.
  • The Auth token will have a fhir_core_app_id which will hold the app the user is representing.
• Using the Application ID fetch the Composition Resource tied to the Application ID.
• In the Composition Resource find the application_config. This can be found by checking the Composition.section.focus.identifier.value == application
• Find the syncStrategy key in the application_config. This should hold the syncStrategy the application requesting data intends to use.
• Using the functionality on the Practtioner Details enpoint fetch the user Practitioner Assignments.
  • The Keycloak UUID to request the Practitioner details will be found on the Auth token in the sub key.
  • Get the ResourceTypes that match the syncStrategy in the application_config.
  • The ID for the resources matching the ResourceType will be used to filter the data from the FHIR server.
  • We will use the _tag=<resource id> param on the FHIR server query.

Acceptance Criteria

• The Data Access Checker plugin can identify the Application ID.
• The Data Access Checker plugin can fetch the syncStrategy for the application in question.
• The Data Access Checker plugin can fetch the user assignments for the user requesting the data.
• The Resource IDs for the Resources matching the ResourceType referenced on the syncStrategy should be added to the _tag param value.

More information on why we need to make this change

• Implementing API RBAC (Role Based Access Control) & Remote Sync ( from the server) for FHIR Core -- Data Access Filter #1604

[rehammuzzamil]

Based on the issue here, I believe, the client (app) would request resources one by one. The server will only be responsible to filter out the requested resources by including the $everything operation and the parameter _tag= in the REST calls to filter the resources by the user assignment.
@dubdabasoduba Please correct me if I am missing anything.

cc: @ekigamba

[rehammuzzamil]

LOE: 7-8 Days

• This issue holds the foundation of the Data Access Checker/Data filtering.
• This would deal with the basic design of the plugin.
• This would also require some R&D to include custom repository model classes (as a dependency) to parse results from the Practitioner end-point.
• Separate Util class might need to be written, to handle the creation of a ServletRequestDetails manually to fetch data (Composition Resource/PractitionerDetails) from the FHIR Server via FHIR Client.

Note: LOE is specified for a PR submission for an initial review.
cc: @dubdabasoduba @ekigamba @f-odhiambo

[dubdabasoduba]

Based on the issue here, I believe, the client (app) would request resources one by one. The server will only be responsible to filter out the requested resources by including the $everything operation and the parameter _tag= in the REST calls to filter the resources by the user assignment. @dubdabasoduba Please correct me if I am missing anything.

cc: @ekigamba

@rehammuzzamil We will not be using the $everything operation. We will on add the _tag parameter.

[rehammuzzamil]

Hi @dubdabasoduba , a quick question, does fhir_core_app_id added as a user attribute to the user from the Keycloak console?

[rehammuzzamil]

@dubdabasoduba Kindly share a sample payload of the Binary resource used to hold the app's configuration (application_config.json).
cc: @f-odhiambo

[dubdabasoduba]

Hi @dubdabasoduba , a quick question, does fhir_core_app_id added as a user attribute to the user from the Keycloak console?

@rehammuzzamil Yes, We are adapting the FHIR web to be able to add this.

[dubdabasoduba]

@dubdabasoduba Kindly share a sample payload of the Binary resource used to hold the app's configuration (application_config.json). cc: @f-odhiambo

https://github.com/opensrp/fhir-resources/blob/main/ecbis/app_configurations/ecbis_cha/application_config.json Here yous go.

[rehammuzzamil]

@dubdabasoduba I have a few questions:

1. As per my understanding if the DataAccessChecker plugin is activated, it will be responsible for checking access logic for all the Resource types against the HTTP GET method. What should happen in the case of other HTTP methods like POST, PUT, DELETE etc.?

2- Another question, the idea of DataAccessChecker is to filter out the results based on the user assignments by adding the _tag param to the requested end-point. But the current implementation of AccessChecker works in the way that it first checks the access/authorization by returning the AccessDecision and then proceeds with the handling of the Rest calls on the HAPI via HttpFhirClient. But as per our use case, we would have to handle the request first, and based on the HTTPResponse, the decision would be made whether the user is authorized to access a specific resource or not.

Kindly share your thoughts on this.

cc: @ekigamba @ndegwamartin @f-odhiambo

[pld]

interested to hear what @dubdabasoduba says

1. I think it should check access for all methods
2. good question idk

[dubdabasoduba]

@pld @rehammuzzamil

1. I would say we might want to allow POST and PUT without data filtering. The reasoning behind this is, we need all the data on the app pushed to the server.

   • If we restrict it means in case data was tagged wrong maybe because of wrong assignments we will restrict the data from being pushed to the server.
   • I however think we can restrict the DELETEs to make sure users do not delete data that they don't have access to.

2. Yes our DataAccessChecker should leverage the HAPI FHIR filtering functionality. We only identify the filter parameters based on the user assignments and then let the HAPI instance filter the data for us.

   • The permissions check will help us check for the resource access permissions.