Questions about list views for approved users for each resourece and approved datasets for each user

[toshiakiasakura]

Hi REMS development team,

I am currently seeking for a light-weight data access management system and I found this project is closest to what I am imagining! Thanks for your contribution for developing such a nice software.

As far as I played around the software, I found the following two functionalities I would want to have for my use-case.

• In each resource page, the list view of users whose approval status, access start date and expiration date are included.
• In Administration page, the list view of users to check who are currently registered or on the platform. Also, when clicking each user name, check which dataset each user has the access to each dataset.

If there is any reason not to implement the above functionality, I am curious to know the reason. Also, I am happy to contribute to implement the above fucntionalities (though definitely I will use the LLM for achieving the above).

[meericsc]

Hi,
Thanks for reaching out, and apologies for the delay in responding.

Regarding your questions:

1. Access rights summary
   We haven’t currently planned to implement this in REMS, but I know some organisations that are using REMS have implemented something similar.

• One (sometimes easier) possibility is to collect authorization information into an external service (some use e.g., a CRM system or general user portal) instead of implementing it directly in REMS.
• As you may already know, even if these information are not directly findable from the UI, the entitlements are available through the REMS API. For example, the entitlements endpoint: https://rems-test.2.rahtiapp.fi/swagger-ui/index.html#/entitlements/get_api_entitlements
• Depending on the use case, some systems collect information of new approved applications via the event notifications: https://github.com/CSCfi/rems/blob/master/docs/event-notification.md#approvedevent
• If this functionality were implemented directly in REMS, one challenge would be deciding where the information should be displayed, how it should be presented, and which users should be able to see it. REMS supports a variety of use cases, and the people administering catalogue items (owners) are not always the same people who process applications (handlers). There is also a separate reporter role with visibility into both applications and administration. One possible approach could be to make this information available to reporters. Roles and their access rights are listed here: https://github.com/CSCfi/rems/blob/master/docs/application-permissions.md

2. View of registered users and the datasets they can access
   We have not previously encountered this request, at least that I could remember, but that does not mean it would not be useful in other deployments.

Currently, these information can be obtained through several different ways:

• You can list users in the REMS application environment by running:
  java -Drems.config=config/config.edn -jar rems.jar list-users

• Or by querying the database directly.

• There is also also an API endpoint for querying active users: e.g.
  https://rems-test.2.rahtiapp.fi/swagger-ui/index.html#/users/get_api_users_active

• And you can use the same entitlements endpoint to query the access rights as mentioned in the first use case.

As with the first suggestion, there are questions around permissions and visibility. In some REMS deployments, listing all registered users and their dataset access rights may be considered sensitive information. While such information is already available through administrative interfaces and APIs, showing it in the UI would make it more accessible. Therefore, we would need to carefully consider which roles should be allowed to view it and whether all deployments would want to enable such a feature.

We do welcome contributions (CONTRIBUTING.md). If you decide to explore this further, we'd be happy to discuss the design and permission model in more detail. We are also always interested in hearing about new use cases.

[toshiakiasakura]

Thanks for the kind and detailed response. It's really helpful to understand that these design choices are intentional — the permission and visibility rules for each role, and the relationships between other datasets, make a lot more sense to me now.

That clears things up, and I don't have further suggestions at this point. Thanks again for taking the time to explain!