As an extension of the infrastructure, a front-end for certain FHIR microservices has been built into the infrastructure. The solution is built with the purpose of being to be an administrative solution for administrative tasks. The solution uses the existing security model of the FUT infrastructure and the resources of the FUT infrastructure. A user accessing this solution needs to have administrative privileges for the areas of questionnaires, care teams, plan definitions, and activity definitions. A user with access rights to this solution does not automatically gain access to the clinical or the SSL domain.
...
User story using a shell application as a micro frontend
In order to To understand the architecture, it is important to understand the concept of micro-frontends. This can be shown by showing how a user is presented with the KAM solution:
When a user accesses the KAM frontend, they are accessing a web application (single page app or SPA) like this:
Here they can push the green button to log on using the FUT infrastructure IdP, like this:
After login, they are presented with a selection of the security context they would like to use in KAM. This selection will determine the set of micro-frontends they have access to.
After this selection, the user is able to can use KAM and its modules with the individual micro frontends. This is shown below:
...
The table listing the careteams (the grey area on the screen) is a separate micro-frontend that is assembled by the browser within the shell application. This micro frontend is a separate component in the FUT infrastructure but is assembled by the shell application for the user. Now that we have a basic understanding of the roles of a shell application, an identity provider (IdP), and a micro frontend, we can have a look at how this has these have been deployed as individual components in the FUT infrastructure.
The component model of the KAM architecture
In order to To describe what has been built and deployed, and how the components interact, we will start off with a diagram with the two main areas of components in the FUT infrastructure cluster. All components are still packaged and released as containers, as every other component on the infrastructure.
...
In this sequence diagram, a number of several details have been omitted, among these is the complex setup behind the logon process after the user hits the IdP, with redirects to the local IdP via SEB.
...
The security model used in KAM is the same as the one used in the remaining FUT infrastructure. This means that the shell application will redirect the user to the IdP using the user's browser, and in this process receive a set of security tokens (JWT). The shell application has the responsibility to do the required refreshes in order to ensure that the tokens are valid at all times when using KAM. The access token is provided to the micro-frontends in the browser’s local storage (with access tied to the KAM domain). They can use the token to do lookups into the infrastructure, and thus will only present data, which the current user has access to, with the currently selected security context.
...
“Fortolket visning” which enables the setup of views with interpretations of collected data from questionnaires
“Handlevejledninger” which enables the maintenance of instructions for different measures, carried out based on the basis of questionnaire results
This setup is possible by mere configuration of the common workplace, with the configuration of new menu items with associated security model.