Authorization strategy design for benchmark dashboard

[rahmandawibowo-vito]

The keycloak authentication has been setup for benchmark dashboard pages/apis, with access limited for users with administrator role at the moment. The next step forward will be to have an authorization system to cater these goals:

1. Benchmark pages can only be accessible for users with certain group.
2. The content in the page will only display stuffs owned by users with certain group.

Additional requirements to this feature:

1. Administrator can still access all pages and contents.
2. No manual roles addition should be put in place to give user access to the dashboard. It should happen automatically.
3. Keep the logic and setup to be simple and scalable.

Proposal

Automatic check using email as provider group

The proposal is to define the group as a provider that is identifiable from the user's email domain (e.g. rahmanda.wibowo@vito.be -> VITO). With this grouping, everyone with their provider email can access all benchmark contents owned by the provider.

The authorization logic will be put in the middleware. The user session containing the email will be checked first before allowing access to benchmark dashboard. To make this possible, a mapping from benchmark to the provider is required, and the server should be able to use this in runtime.

Mapping algorithms with providers in build time

The mapping can be build correctly from link rel=provider on the algorithm's service records (enabled by this PR https://github.com/ESA-APEx/apex_algorithms/pull/284/files). Since these records are read in build time, this will happen during the catalogue pages generation phase. We can execute a script to export this mapping into a file (csv or parquet), which can be included in a Docker image later. When the server is starting up, the Duck DB will import this file as a table that can be queried easily by the middleware.

When a new algorithm or provider is introduced, the web should be rebuilt to update the mapping (together with the pre-rendered pages).

[rahmandawibowo-vito]

Do you have comments or feedbacks @JanssenBrm ?

[JanssenBrm]

Thank you for this initial proposal @rahmandawibowo-vito. This sounds like a good starting point. The main challenge is to link the email address to the provider as this might not be an exact mapping, although this doesn't seem an issue with the current setup. To which field in the provider configuration file would you map the email domain?

[rahmandawibowo-vito]

I'm planning to use the link ref="website" https://github.com/ESA-APEx/apex_algorithms/blob/main/algorithm_catalog/eurac/record.json#L2 here for email mapping, under the assumption that the email domain will be the same with the website's root domain. And then use the provider id to map the algorithm with the provider.

I don't know about the user email from other providers outside of VITO, so probably my approach needs some further tweak 😅