Dynamic database proposal: how to add your own file groupings to the CoMPAS database in order to grants rights to it

[Sander3003]

Based on this investigation (#521) we like to move on with roles. However, we need to give organizations more say in how to structure the database. This should be configurable installation time.

Acceptance criteria:

Proposal how manage dynamic SCL file groups

1. How to know what SCL file belongs to a user defined database "group"(e.g. private type in SCL to store this)?
2. How to configure the SCL "groups"?

Impact on the current state

Needs to discussed the CoMPAS community

Out of scope:
CoMPAS user settings (e.g. what plug-ins to load in what role)

[clepski]

SCL File Groups

Use case

For Alliander we need to restrict access to certain files, e.g. LNodeTypeLibrary and BayTypical, to a subset of users. The current mechanism only allows restricting file access per file type: Read, create, update and delete for .scd or .ssd and so on.

This feature would allow users to create file groups and assign files to file groups, for example file group 'BayTypical'. We want to extend the existing role based access, but still allow the admin to create their own file groups, because these will be different for different utility companies (other companies might use application profiles instead of bay typicals). The role assignment will be managed at installation time.

Solution idea

• Add a table with file groups to the DB and UI to allow users to create entries
• Add a many-to-one relation from SclFile -> FileGroup
• If a file is not part of a FileGroup the current behavior of permission per file type applies
• Add UI to assign SclFile to FileGroup
• Add roles for file groups, the exact mechanism is not clear right now, do we want to reference them by id like file_group_$id$?
• Add permission checks when fetching or editing files from the BE, note that the current route-config based approach won't be enough

Open questions

• Do we keep the current permission system as is: Read, create, update, delete per file type?
• Do we want to seed some file groups like LNodeTypeLibrary?
• Do we need Read, create, update and delete permissions or is read, edit (create, update, delete) enough?
• Mechanism for setting the allowed file groups to users in some middleware

[Sander3003]

To answer your questions:
Do we keep the current permission system as is: Read, create, update, delete per file type?

Do we want to seed some file groups like LNodeTypeLibrary?
Yes

Do we need Read, create, update and delete permissions or is read, edit (create, update, delete) enough?
Take over the exsisting approach

Mechanism for setting the allowed file groups to users in some middleware?
@clepski any suggestions?

Add UI to assign SclFile to FileGroup?
An UI can be added later, for now a configuration at depoyment time should be fine (we don't expect to changes groups that often).

[Sander3003]

What are the next steps?
A small investigation into Mechanism for setting the allowed file groups to users in some middleware is needed.

Architecture or straight into stories?

[david-monichi]

Smaller thoughs:

• is assigning SclFiles to FileGroups at deployment time a valid solution? Aren't files to dynamic for such an approach?
• colleagues of mine introduced https://openfga.dev/ for such challenge in a different project and did not develop the authentication themselve. You probably get more then you need but on the other side the whole authorization could be centralized with such a framework. Some questions/answers might needed to be reviewed but that must not be bad. Biggest advantage, no additional authorization complexity in the backend-services. We probably would get some support from them