Safely Communicate With FHIR Server Using Basic Auth

[DiCanio]

There is a need for communicating safely with the FHIR server backing the middleware using basic auth. That's because the FHIR server is going to be deployed in an exposed fashion requiring some sort of auth.

Basic auth should be configurable by providing a username and password preferentially using environment variables. If none of these is provided then basic auth should be rendered disabled.

[DiCanio]

Basic Auth is currently not supported by the Highmed API being used as all known implementations do not allow for registering a HttpAuthenticationFeature. So to properly implement this feature we will need to request either a basic auth implementation or an API change from the Highmed team.

If this is not viable due to timing restrictions regarding the project we could also pursue one of the following routes:

1. Use a proxy in front of the FHIR server
   • simplest solution (everything already in place)
   • API supports proxy authentication
   • limited to a single hop unless proxy is configured accordingly (would be sufficient in our case)
2. Run a self maintained client implementation supporting basic auth
   • copy of FhirWebserviceClientJersey class
   • adjusted constructor that allows for passing in a HttpAuthenticationFeature instance
   • needs to be maintained until a corresponding implementation is available in upstream
   • closest to what should be used in the long run
   • most effort

Any thoughts on this @alexanderkiel, @juliangruendner?

[alexanderkiel]

Would it be possible to access Blaze over an internal Docker network so that we don't need authentication? I currently work on samply/blaze#408 that will allow multiple ways to access Blaze, so that the external requests could go over the reverse proxy adding Basic Auth and the BPE goes directly.

[DiCanio]

Basically it is possible to do so but it would require us to adjust the num-codex/codex-deploy project so that FHIR server and parts of the middleware are on the same network. I would need to have a look if this affects other deployment configurations (Aktin etc.). Maybe @juliangruendner already knows about it.

Since it seems we need a reverse proxy either way, proxy authentication seems to be the solution with the least potential of conflicts to me.
However, we should give both options a try and see how they turn out.