Handle client registry feedback for multiple CHIS instances

[kitsao]

1. We know that there eventually will be 47 CHIS instances
2. Currently, just one OpenHIM production server was set-up.

We need to efficiently and correctly serve requests from the many CHIS instances to one OpenHIM and back.

[karimkkanji]

Here is one approach:

1. We can have multiple entries in the env.
2. Let the /client have add additional field of the county. i.e: /client/NAIROBI or /client/STAGING.
3. Based on the instance, the correct mapping will be gotten from the passed value from eCHIS and passed via a global variable that can determine which instance is currently sending data from.
4. There is need to add the instance to the endpoint on eCHIS to allow correct mapping to the right server defined in the env.
   This can be extended to all other endpoints.

Here is the branch with the sort of implementation to allow this to move forward if this proposition is okay. https://github.com/moh-kenya/echis-2.0-integration/tree/ft/multi-tenant-echis

[karimkkanji]

The above branch contains the following proposed changes to allow for multi-tenant handling of the various instances: https://github.com/moh-kenya/echis-2.0-integration/tree/ft/multi-tenant-echis

1. An env sample file that contains all the credentials for all the servers and their logins.
2. A new route that needs to be added to eCHIS /instance/{{rp_instance_county_in_caps}}/client and /instance/{{rp_instance_county_in_caps}}/referral/facility
3. Picking of routes from the env based on the passed {{rp_instance_county_in_caps}}
4. Routing to the right instance of eCHIS based on the picked values from .env

@kitsao @freddieptf Let me know if this approach is sustainable.

[freddieptf]

Great start @karimkkanji, here are my thoughts

An env sample file that contains all the credentials for all the servers and their logins.

I'd suggest getting the credentials directly from the 1password API

A new route that needs to be added to eCHIS /instance/{{rp_instance_county_in_caps}}/client and /instance/{{rp_instance_county_in_caps}}/referral/facility

This will increase chis deployment complexity, I had suggested a hacky workaround setting the client ids on OpenHim as the instance's domain which will be available in the request headers as x-openhim-clientid. This way the chis config doesn't have to change. One downside to this approach is the client id is not editable so any changes to domains would mean creating a new client on OpenHim

Picking of routes from the env based on the passed {{rp_instance_county_in_caps}}

If we could get this from the request headers then that would be ideal

Routing to the right instance of eCHIS based on the picked values from .env

Again, I'd suggest using 1password API for this so any changes to the secrets can be automatically propagated downstream to all dependents

[karimkkanji]

@freddieptf I like the idea of the headers. It may help us indeed to pass the values to the mediator. I have one concern:

1Password is a paid service, isn't it? Can we have one that is not paid?

[freddieptf]

1Password is a paid service, isn't it? Can we have one that is not paid?

@karimkkanji So we don't block ourselves waiting for infra, lets move forward with the .env file. Create a PR so we can do more detailed review of the approach

[karimkkanji]

@freddieptf I took the initiative to use the X-OpenHIM-ClientID which is working as expected. Creating a PR for this: https://github.com/moh-kenya/echis-2.0-integration/pull/125