[Login] Make the FHIR & KeyCloak server details configurable

[dubdabasoduba]

Feature context

• Currently, we are allowing users to configure the app behaviour via the Composition resources. This is the driving factor of the SAA (Single APK Approach).
• This means the client can get the APK and use them for different uses and on different servers.
• We however do not yet allow the configuration of different servers on the APK.

Describe the enhancement

• Create a setting page to allow the users to update the following data
  • FHIR server URL.
  • Keycloak server URL
  • Keycloak Realm
  • OAUTH Client ID
  • OAUTH Client Secret
  • OAUTH Scope
• These details are to be saved on the device's shared preferences.
• The display of this settings page should be configurable with showing it being the default behaviour.
• Any time the settings above change the APP database should be cleared. This will mean the app has to be reconfigured from the app ID screen.
  • Any time the settings change the user should be shown a confirmation dialogue explaining the risks of the change. The message should read something like "Saving these changes will lead to clearing of the Application data. This means all unsynced data will be lost"
  • If they click yes, then the settings are updated and the app database is cleared.
  • If they click no, then the change is revoked.
• This menu to the settings page should only be active when the user is online. This will help prevent users from changing the settings without the ability to remote login.

[f-odhiambo]

Do we need a design for this? @dubdabasoduba

[pld]

Since this has that data deletion implication, should an app config be able to control whether this option shows to the users at all?

Do you have to be logged in to access this menu?

[dubdabasoduba]

Since this has that data deletion implication, should an app config be able to control whether this option shows to the users at all?

Do you have to be logged in to access this menu?

Nope, you can only access it when logged out. It's mostly for initial setups.

Yes, I think we can hide or show it based on a configuration.

[dubdabasoduba]

@ellykits @Rkareko Do you guys think moving some of these configs to the config_application makes sense? We can have the sensitive bits added to the app via the settings page.

But the rest I think can be on the config_application.json

cc: @f-odhiambo

[dubdabasoduba]

@ellykits @Rkareko Do you guys think moving some of these configs to the config_application makes sense? We can have the sensitive bits added to the app via the settings page.

But the rest I think can be on the config_application.json

cc: @f-odhiambo

I think we can also have the sensitive parts added via the configs. We just have to encrypt and then write the decrypting functionality on the FHIRCore app. This would make the device setup easier since the user won't have to type anything that concerns the server setup.

[dubdabasoduba]

@allan-on

R&D requirements

• We want to store encrypted credentials on the FHIR Server. This would be on the application_config
• We however want to be able to decrypt the encrypted credentials on the App.

[ndegwamartin]

I foresee some challenges with the above approach, mainly in how we'd share the encryption key between the server and the client. We might need to research some more on this to make sure we exhaust any possible approaches there. Also if we use that approach I think we only really need to secure the OAUTH Client Secret, the availability of all the others should be fine publicly. We could however encrypt both the OAUTH Client ID and Secret.

We could also explore an alternative approach that does not requires us to use cryptography but rely entirely on Keycloak.

How this would work is that we can have a web page on the FHIR Web portal that has the QR code with details of the server of interest.

In the case that we need to support a situation where the same user can log into multiple servers then we could have a number of QR codes displayed alongside their Server IDs to help easily identify them.

Sample workflow would look like this:

• FHIR core client App ID Settings page loads, User enters App ID
• Configuration resources are synced to the FHIR Core client app, on completion a scan QR Code view is launched
• The user logs in to the portal using their credentials (probably on another device) and navigates to QR Code view
• The user scans the QR code which saves the content (OAuth config details) securely on the device

Pros

• Maintain security of config details with no need to worry about complexities of cryptography
• Uses Keycloak for authentication which is already integrated

Cons

• We need some extra LOE for work on the Front End web
• At the facility/user level we need at least two devices where one renders the QR code for other users to scan

cc @dubdabasoduba @pld @allan-on

[pld]

yea good points, let me review in further depth, unassigning @allan-on for until we've resolved and unblocked

[pld]

I'm not sure how to prioritize this issue, a lot of this sounds like useful for debugging, maybe important enough it's high priority, but this feature is not anything we'd want users to have to use, you'd be using it if something went wrong. When setting up clients on phones, I don't think it would ever be routine to change these settings.

I also get the sense there are a couple issues that need to support the UI portion of this issue. Like loading these settings from the app config files, is that something we do now, or is that something new?

From the UX angle, we want to minimize the work the user has to do. Right now they have to enter an app ID and then a username/login, it's hard to get around that as a minimum. If we think of the default settings in the client as pointing to a federation server, maybe when someone enters the app ID, it then pulls that app ID which could change these settings, change the server URLs, then the user logs in, it pulls the rest of the app config from the new server URL, auths against the new keycloak URL, proceeds.

[dubdabasoduba]

@ndegwamartin @pld
Usecase

• An new implementation wants to use a new server for the APK we have created for them.

How to achieve this right now

• They would need to update the local.properties to add the server URLs and OAUTH credentials.
• They then build an APK from that.

The proposal

• Have a configurable way to configure all the server URLs and OAUTH credentials. This will remove the need for an implementation to change the local.properties

Implementation proposal that uses the configuration work

• Add the Keycloak config details to the application_config.json
  • This is where the encryption thought comes in.
    • We need the OAUTH credentials for the users to even authenticate the users against keycloak.
• Update the settings page to just allow the FHIR server URL configuration.

Proposed implementation user workflow

• The user launches the app, they are redirected to the FHIRCore Application ID page
  • We can redirect them to the settings page if the server URL is not present from the local.properties
• They then enter the APP ID.
• We fetch the composition resource and get the keycloak details the same somewhere probably on the secure shared preferences.
  • The composition resource get endpoint does not try to authenticate if the auth token is not provided. That is why we can download the configs before logging in.
• The fetched keycloak details & auth token generated after login are then used for authentication all through the app.

@pld I agree this is not a priority for the clients we support and any that have tech teams. I think it increases our configurability capabilities.

[pld]

Cool, I think for now only allowing the URL to be modified, pushing everything else to the app config and keeping it out of the local props/not requiring an APK build makes sense

[pld]

this'll start coming up more and more esp as we have multiple FHIR servers we host, so that definitely gives it priority, it'd be less effort to do a server urls/etc in config files issue than to maintain multiple APKs just for the sake of modifying those values

[ndegwamartin]

If we determine that at any one time the provider/user can only be assigned to one application (read one App ID) then after the settings configurations load, the app could launch a WebView which loads/points to a secured Frontend web endpoint with a JSON response that has the OAUTH details above.

Since it is secured by user(Keycloak) credentials the values (json response) will only be returned after the user authenticates (Web view will redirect/provide the Keycloak login page). We could then parse that response to persist the values of interest therein.

This approach removes the requirement stated above of having at least two devices to scan a QR Code for the OAuth details.

[ndegwamartin]

In the case that we will still be editing the local.properties file as tracked by this discussion then we might not need to have this process as configurable.
We could always configure these details as well on the local.properties file when bundling a release for the client.

[dubdabasoduba]

In the case that we will still be editing the local.properties file as tracked by this discussion then we might not need to have this process as configurable. We could always configure these details as well on the local.properties file when bundling a release for the client.

@ndegwamartin This method will work for the implementations we manage or the clients with tech teams. This issue is meant to address situations where a client just picks the Quest APK and wants to use it as is.