google/fhir-access-proxy

A generic proxy server for applying access-control policies for a FHIR-store.

fhir-access-proxy's Issues

Check Health and Stability of Releases (Gateway)

Use HAPI client for FHIR API calls

The main job of the proxy is to relay FHIR calls from the client to the FHIR store server. But there are cases that a new FHIR API call is initiated by the proxy, e.g., to check existence of a patient, checking/patching access List resource, etc. For these cases, instead of handcrafting the query, we should use a FHIR library like HAPI FHIR client.

Design location/role based AccessChecker

Design an access control model which can solve requirements for location/role based access control from different partners.

Parent issue - #103

Support Update as Create Operations

http://hl7.org/fhir/http.html#upsert
Add support for update as create operations in the existing Access Checkers:

1. PatientAccessChecker
2. ListAccessChecker

Allow request mutation based on Access decision

Parent bug - #108

ONA enabled preprocessing of request for an access decision - opensrp@09584ef.

We wanted to support Query rewrite option in the design doc - https://github.com/google/fhir-gateway/blob/main/doc/design.md

Create a public version of the original design doc.

We need to update the original design doc and create a public version of it.

Clean up error messages to the client

Right now, in many error cases, we send large stack-traces to the client. This is probably of little value to the proxy user and the proxy developer should have access to the logs (which is were these traces are already printed and should be kept).

Pass body of FHIR operation error responses to the client

If there is an error in a FHIR API call, we currently do not pass the HTTP response entity body to the client.

Create sample plugin using Fhir Gateway maven artifact

Create a sample plugin in fhir-app-examples using our maven artifact to build new plugins.

Release new build to maven

We need to release all the changes to maven to allow partners to use the latest Fhir gateway changes.

Reevaluate test infra options

We currently use Kokoro for our e2e test-infra. The main drawback of this is that it depends on some [Google] internal tools/config. We should evaluate other options like Cloud-Build or GitHub-Actions and possibly switch to one of those.

Refresh docs to align with new name for component

Sounds like we're switching to either FHIR-info-gateway or maybe just FHIR-gateway. In which case, we should be updating various parts of the docs & diagrams in here, like this on here:

https://github.com/google/fhir-access-proxy/

May need to update package / repo names, etc.

This can wait for a fast follow.

Support extracting all patient IDs when URL contains ORs

Reported by @omarismail94

The proxy does not support having ORs in search parameters.

If I do a direct request to GCP FHIR Store, it works:

curl -X GET -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  "https://healthcare.googleapis.com/v1alpha2/projects/[PROJECT]/locations/us/datasets/[DATASET]/fhirStores/gcs-data/fhir/Observation?_id=3f6cb1cf-2c0d-739d-0790-5ab8a26daf2e&subject=Patient/92a950eb-6aae-0e82-c297-d91585b22edf,performer=Patient/123"

If I send the same to proxy, I get an error saying that the patient id cannot be found.

Also we should turn any request that has searches that contain OR, e.g. subject=P1,P2 into an access check for both P1 AND P2, i.e. client should have access to P1 and P2.

Return '403' Forbidden error message to an unauthorized user

Current
When user access is denied, an error code of 401 is thrown.

Expected
It should return 403 Forbidden error message to the unauthorized user.

It worked by:
Updating exception to ForbiddenOperationException.class instead of throwing AuthenticationException.class in
https://github.com/google/fhir-access-proxy/blob/3bf8a400e257f234f677154442f63570cd131307/server/src/main/java/com/google/fhir/proxy/BearerAuthorizationInterceptor.java#L238

cc : @bashir2

Set the Prefer header properly when updating a resource

For post-processing and updating the list of patients, we rely on full resources to be returned from the server. We should not rely on the FHIR store default config and instead set the "Prefer" header as described in the spec.

EPIC: As an early adopter, I am able to directly use the Gateway in production without maintaining a fork.

Support fetch/mutate resources by ID

We currently have support for extracting patient IDs from a request URL (or a Bundle) and the idea is that the AccessChecker decides whether to grant access based on those patient IDs. One implication of this is that for example to fetch an Observation by ID, the client needs to provide the corresponding patient query parameter as well. To support directly fetch/mutate a resource by ID, we can first fetch that resource from the server, extract the patient from it (based on patient compartment) and then decide. This is a useful feature to be implemented in the shared library in the server module.

Add support for SMART-on-FHIR scopes

Currently in PatientAccessChecker we do not apply the SoF scope constraints. We need to support patient/*.* scopes as this AccessChecker is intended to honor patient launch/scopes scenarios in the SoF spec.

Resource finder utility for processing bundles

Parent issue - #108

Provide a resource finder for processing bundles similar to ONA's implementation - Resource finder.

Support POST based search operations

http://hl7.org/fhir/http.html#search
Add support for POST based search in the existing Access Checkers:

1. PatientAccessChecker
2. ListAccessChecker

Track test coverage

We should track and expose test-coverage data publicly. A long time ago, we used Codecov for the Analytics repo but we need to check the spectrum of possible options now again. This is also related to #98 and what we choose for continuously running our tests.

Decide how to handle access list update failures

Currently, if the post-processing step fails, it is possible that a Patient resource might be added but its ID is not added to the access list.

As a developer, I can follow instructions to see how the FHIR gateway can be used to support Smart-on-FHIR apps

Update BACKEND_TYPE flag value name HAPI to something more generic

HAPI should be used for generic FHIR servers; it would be good to name the option to something more generic as well.

Support gzip encoding for data transfer

We should support "gzip" encoding for fetching responses from the FHIR resource server, as this is crucial towards optimising for network bandwidth. The client can tell the server that it can accept the "gzip" encoding with Accept-Encoding header value

Response in AccessGrantedAndUpdateList can lead to memory overload

Reported by @omarismail94 :

When we send a Bundle, we load the entire response in memory. Depending on the maximum size, this might cause memory issues for the proxy.

See the BearerAuthorizationInterceptor.replaceAndCopyResponse method as a way to avoid this by using a StringReader.

Invalid Access Token should return 401 Unauthorized Access

Current:
When an invalid or malformed access token is sent in the header, it returns 500 Internal Server Error.

Expected:
When an invalid or malformed access token is sent in the header, it should return 401 Unauthorized Access.

cc: @bashir2

Evaluate the changes done by ONA to the forked FHIR Gateway server component

Parent Issue - #108

Evaluate requirements/feasibility of supporting custom endpoints

The current architecture assumes that any request to the gateway is eventually passed to the FHIR server for returning a response. There are use-cases where we may want to support custom (non-FHIR) endpoints, e.g., in the context of sync as mentioned in #122. There are different ways to support this. We should first evaluate the requirements for this feature and make a conscious decision whether to support it. If the answer is yes, we should have a mini-design to close this issue.

Clean up sample Keycloak tokens

Currently we keep many of the default claims in the sample Keycloak config. This is confusing to the users who try the gateway for the first time. We should clean-up these default tokens and remove most of the optional/unnecessary claims.

Support DELETE operations

We currently do not support DELETE operations in the access-checkers; we should fix this.

It's currently a P3 because it is not clear how important it is for the immediate use-cases we know of.

Support client supplied Accept header in API requests

Proxy is always setting the response content type to a default header - proxyResponse.getResponseWriter
We are ignoring the Accept header sent by the client.

We expect the FHIR response to be in JSON. If we send application/xml then this will break the code.
fhir-access-proxy/plugins/src/main/java/com/google/fhir/proxy/plugin/AccessGrantedAndUpdateList.java

I tried the create Patient API with "Accept: application/fhir+xml" and I get this error in AccessGrantedAndUpdateList "Content does not appear to be FHIR JSON, first non-whitespace character was: "

We need to add support for client specified Accept header and return the corresponding Content-type

Abstract out bundle processing in AccessCheckers to a separate entity

In reference to the conversation here in PR , remove the duplicated logic of Bundle processing in PatientAccessChecker. Possibly refactor any Bundle processing related code in other AccessCheckers as well.
Idea is to create a separate abstraction for Bundle processing which can be used by different implementations like PatientFinder and for any specific implementation of Bundle processing in the AccessCheckers.

Support `batch` Bundle operations

Reported by @omarismail94:
Right now, we only support Transaction bundles. Look into supporting batch bundles.

Update @bashir2:
Marking this as P3 until we have a specific use-case that needs it.

Support AllowedQueriesChecker for Bundle Entry Requests

As of now, the AllowedQueriesChecker only checks for by-passing any access based checks on a request by the request path. However, in case of a bundled request, we should allow the same checks for by-passing on each bundle entry request.

Allow unauthenticated requests for certain endpoints

Parent - #108

ONA requires capability to allow access without a valid access tokens for some APIs. We should allow unauthenticated allowed queries.

This is used to fetch Composition and some Binary resources before login.

Formalize the release process

We need to have a clear recommendation on how to use the access-proxy core for users who develop their own AccessChecker plugin. As part of this exercise we should create our own release process, possibly including pushing binary artifacts to a binary repository. The users, should not need to fork the server code.

This issue does not seem to be relevant to this repo; closing.

This issue does not seem to be relevant to this repo; closing.

Originally posted by @bashir2 in #9 (comment)

Collect access control requirements from different partners

Parent Issue - #103

Implement location/role based AccessChecker

Any practical Healthcare solution needs some form of Role based access control and also limit the access based on the primary location, organization, careteam of a practitioner.

We should support a configurable access checker to ease onboarding process for our partners.

Blocked on

• #105

EPIC: As ONA, I can use Gateway maven artifact for production use case without a fork

ONA has created a forked repo - https://github.com/opensrp/fhir-access-proxy

They have updated the server and the added their plugin.
We should try to bring the server changes to the main repo and help them to just created their plugin using the released maven release for the server.

Sub-issues:

• #109
• #115
• #116
• #117
• #122

Header passing revisit

We should revisit what headers we pass to the FHIR store; in particular missing If-Match and ETag is currently a bug. In general, we should make sure all FHIR related headers are passed to the FHIR store or dropped for good reasons.

Impossible to solve

.

Request mutation for POST requests

We added support to mutate query params for GET Http method in #122

Currently there is no requirement for supporting mutates for the post body.
We intentionally wanted to restrict any random mutation to the payload by the gateway.

This might be required for Search by POST. We can think of supporting this after we fix #87

We should re-evaluate this in future based on the client requirements.

Release new image for FHIR Gateway

While running through the fhir-app-examples instructions, William and I noticed that the instructions make references to the following docker images:

us-docker.pkg.dev/fhir-proxy-build/stable/fhir-access-proxy:latest

Two things here.

1. We shoudl probably update the naming to be FHIR-gateway.
2. When we checked this image, it looks like it was last built / released in mid-2022.
3. Upon fixing the name / path, we should go back and also adjust the instructions back at the link at the top.

Make a new release 0.2.0

We have had several important features over the last few months and that warrants a new release; namely:

• Improving SMART-on-FHIR support
• Support for mutating the input query parameters
• Improved AllowedQueriesChecker
• Support for gzip responses

Merge the server changes done in the forked repo

Parent Issue - #108

Modify Allowed queries checker to support path variables and method type validation

Parent issue - #108

ONA's implementation - opensrp@55bb437

Document PatientFinder better

PatientFinder is an important interface for developers implementing access checkers. Create a page for how to use PatientFinder specifically.

As a developer for OHS, it would be nice if the example / test different configurations of HAPI were the same.

We use HAPI in a few different situations - end-to-end testing (automatic & manual) and for illustrative purposes.

The one in Gateway is nice because it has data preloaded into it.
But, the one in Data-pipes is not as nice because you have to run the uploader. And we cannot use the one in Gateway because data-pipes depends on having Postgres as the underlying database.

Suggestion:

• Look into changing the Gateway version to be PostGres, and then modify the instructions in Analytics to leverage that one instead.