User Management

[GeoffreyKarnbach]

Description A list of all possible features:

• User Accounts
• Data protection (by user affiliation)
• Permissions system
• Group Management
• Impersonate User
• SSO
• Management page in Admin UI

User Accounts

Right now, no real users exist, the IDs provided from an authentication provider through SSO are used to authenticate users. A new user entity should be created containing the ID, the name and the email for instance (once the user has used SSO to sign in), as well as an information about the Affiliation to a given information.

Data protection

Right now, only members of the institution where the DMP Tool is deployed have access to the DMP Tool (and therefore for instance the information from the project database => DMP TU Wien Tool, SSO with TISS, only for TU WIEN members).

When implementing user accounts, members from other institutions could access the DMP tool. The access to potentially sensible data, such as the projects or the person database should be restricted to members of a given institution (for instance by setting a institution ID in a config file and comparing it to the affiliation of the user, obtained through the SSO provider).

Permissions system

A User should have different possible permissions levels on a DMP:

• Read
• Read + Write
• Owner: The owner can transfer the ownership (and therefore lose it) to another user (should probably also be able to be changed in the Admin UI if the owner loses access to his account?)

Group Management

Instead of adding users manually to a project, users could be added to groups to share permissions with an entire group. These group could either be project specific, but there could also be "global" groups or admin only creatable groups, that can always be selected. Those groups could refer to departments or research groups for instance.

DMP Owners could share access to single users or entire groups, the backend would have to check for permissions therefore also by "resolving" the groups into their members. The highest permission should always apply.

Impersonate Users

Similar to how an Admin can view the Tool from the perspective of any arbitrary user in Invenio RDM, an Admin should be able to "borrow" a JWT for any user, while still keeping his own JWT. To be able to escape the "user perspective", the frontend could just switch the JWT back to the admin JWT.

SSO

In order to allow users from different institutions, an SSO provider such as ACONET or EDUGAIN should be used, instead of a institute specific SSO provider.

Management page in Admin UI

Users should be able to be filtered in a list view in an admin only panel, to be able to edit / delete (?) them. Related to: https://github.com/tuwien-csd/damap-frontend/issues/322

[GeoffreyKarnbach]

Clarifications on the User Management:

This issue is a major effort for DAMAP that would mainly allow having external users (with non-local institutional SSO) being able to use DAMAP and see DMPs (or selected DMPs).

The features should all be implemented individually (see the list at the top of the description).

[ValentinFutterer]

Since Invenio and DAMAP have a very similar way of authenicating users, we talked to Max, since he implemented a way for guest users to use TU-Wiens invenio instance, without them allowing for free account generation.

He solved this issue, by authenticating users through the EduGain federation, a federation of university identity providers. If a user authenticates through EduGain, he/she first chooses their university affiliation and then gets redirected to the institutional login - as opposed to directly getting redirectedto one predefined identity provider. If we would implement this, most guest researchers could be given easy access to the DMP-tools of single universities. Through the data returned by the different identity providers, it would be possible to restrict access to certain sections, like the project db.

This could be a little tricky to implement however, since the EduGain federation speaks SAML, which is a protocol similar to OIDC. Since DAMAP is geared towards OIDC, we would need to either rewrite verything, or add some translate containers, that take care of translating SAML to OIDC. Max created a pipeline for this, he used Keycloak, Satosa and DISCO as an inbetween. DAMAP would probably need a similar solution, although this has to be discussed more. and needs further research. This would also make the integration between tools like DAMAP and Invenio way easier, since then both would store the same University-PersonID for each user.

Integrations between different universities would be way harder though, since EduGain by default returns only the SAML pairwise ID for each different Service Provider, which is a unique ID per SP per User. What we would need is the Global ID per user, which only very few identity providers give out.