Provide Authentication support in test page overlay

[rehammuzzamil]

Fix broken web UI (Test page overlay) by providing Authentication support.

Cause of broken UI Due to the Keycloak Security Configuration brought into the JPA Server code, API redirects it to the default login page of the Keycloak as per the default behavior that response is in the html/text format. But as per the CapabilityStatement.class, the mentioned content type is not supported by the API content type. This breaks while fetching and loading the Conformance Statement that has all the set of rules to which the FHIR Application is compliant. It throws away NonFHIRResponseException at https://github.com/opensrp/hapi-fhir/blob/38436e5c1bd04e7a4ca81f078eb18ddabc2bd533/hapi-fhir-client/src/main/java/ca/uhn/fhir/rest/client/impl/BaseClient.java#L576

Possible Solution

• Redirect to the default Keycloak Login form whenever "/" end-point is triggered

• Save username/password in a map (until a session is expired) to be used later

• Keycloak Fetch Token API should be triggered every time an API is triggered

• Introduce an Interceptor to add an Authorization header with theBearer tokenfetched above

• Possible Hook to be used here is: @Hook(Pointcut.SERVER_INCOMING_REQUEST_PRE_PROCESSED)

• We need to add logic to check if there is an already existing Authorization headerpresent in the HTTP Request then skip this step.

Challenges/Open questions

• How to keep track of user active sessions?

cc: @f-odhiambo @dubdabasoduba

[rehammuzzamil]

A quick update regarding initial RnD:

• During the RnD process, I have figured out that there is also another way to resolve this issue. The approach would be to customize CapabilityStatement and provide support of the html/textformat. The CapabilityStatement can be customized by creating a server interceptor and registering it against the server. This interceptor should implement a hook method for the SERVER_CAPABILITY_STATEMENT_GENERATED pointcut.
• With this approach, we also need to register a new parser to decode the html/textcontent type as the current flow fails to parse it and throws the same exception.
• From the implementation perspective, EncodingEnum is the class where all the possible parsers are defined and their relevant implementation is provided in their separate classes by extending the BaseParser class.
• The last step would be to add/register parsers in the FHIRContext class.

Based on initial high-level RnD Pros:

• We won't have to manually redirect to the default Keycloak Login Form.
• We won't need to take care of or manage web sessions.
• The call for fetching token and an Authorization Interceptor to plug in the token in API calls won't be needed as with Swagger once the user authenticates through the Keycloak login form an Authorization header already appends to each request.

Cons:

• Lots of code level amendments and changes in the base repo i.e. Hapi FHIR https://github.com/opensrp/hapi-fhir
• Code-level extension of customizing a CapabilityStatament interceptor to reside in a hapi-fhir-opensrp-extensions repo.

I will proceed with the in-depth RnD and share further details here. Please feel free to share your thoughts and comments on which approach should be used for further investigation. @dubdabasoduba cc : @f-odhiambo @maimoonak