A take towards exploring better user access management

[mehta-pooja123]

UOP is a vast and complex open source software. It provides functionality to various types of people grouped as per roles.
These groupings come from AD-Groups or mapping secured within our databases.

As the software is now growing and being adopted or under review for further collaboration, we are thinking of a way to bring more transparency around who has what role and within a particular role, what type of access(read, write, edit, delete, download, upload etc) a user gets.
We would like to have an opportunity to define finer controls over resources used within this software and allow collaborating facilities more freedom over how their roles are defined and the access to the resources that they allow.
By resources, we mean - calls, proposals etc etc.

The plan is to have a system closer to UOP that maintains and establishes access management rights around various resources for this software. To bring transparency, easy management and audit around roles and permissions mapping for each and every type of user (UO, Reviewer, Sample safety etc)

Points to consider:

1. We realized recently that many departments (STFC, ESS, ELI and more looking to collaborate) have different ways of getting authorization information for a user and we do not have a common contract established to say that once we have this level of information about a user, then the software is supposed to behave a certain way.

   For example, (probably) ESS gets instrument information as part of authorization information for an instrument scientist which STFC and ELI does not.

   Issue: Establish common contract for receiving authorization information for a user when he/she/they logs in

2. Identify few (or possibly all) usecases where permissions are explicitly maintained within the code rather than driven by access management.
   And run them against our design or plan to see if it can be solved by our suggested approach.

   For example, instrument scientist in STFC must be able to see proposals across all calls of their department; unlike ESS where they are limited to the proposals they are assigned to.
   Or FAP reviewer on STFC would not be able to reference reviews from other FAPS on their proposals

3. Support dynamic role creation and permissions around resources mapping. Finer controls for access to each resource type should be assigned as well (Read/Write/Delete/Edit)

4. Draft the design/plan around what STFC (or respective departments) actually needs as their role and permissions requirements

5. Every Action around roles and permission must be audited