authentication for EFM projects

[mujakob]

right now all routes are "open to public" specific projects need specific authentication (maybe add a field "user group" to the project?) which manages access maybe the entire EF-M needs it's own authentication table? these and many more interesting design decisions are waiting for you to solve them!

[johnmartins]

If we assume that one instance of the SED-Lab server will be accessed by only us and (max) one company, then that simplifies things greatly. I think we discussed this during the last meeting. What do you require for this application other than a specific role for administration, and a user role? Could you try to describe what you want to do?

[mujakob]

well for the start this is definitely working - but at some point i would like to be able to access only "my" projects, or the projects i am affiliated with. And the company might only want to access the projects about GKN, and not clutter his dashboard with the research and development projects, or the likes... of course it's not a security issue in the beginning, but rather a convenience-thing. but i think it's something that should be implemented rather soon since it may have an impact on the table structure and basic API setup?

[johnmartins]

The way I see it this should not be a part of the security layer. Instead, we have (at least) two other options:

1. A E-FM project should also include information about A) who made the project and B) who has access to the project. Thus, when listing and accessing projects a simple check can be run to see which projects a users should be able to see and have access to.

OR, possibly more in line with the vision of the SED-Lab:

2. A "Project" spans over the entire SED-Lab and may utilize several SED-Lab applications. Thus, project handling should be implemented in the core, such that it can be accessed from ALL applications (not just the efm app). In that case, the E-FM project would simply contain a reference to which project it belongs to. A user can only see the projects he/she has created, and the ones that he/she has been "invited" to (or whatever mechanism we should have for sharing projects between members).

Do you agree? If so, does any of these strategies sound good to you?

[mujakob]

That sounds excactly like what i had in mind! right now - mainly since i see it as quick and still probably suitable for the future - i would vote for 1) if i understand it right that would require a) a field "owner" in the project table and b) a table "access" in the EFM db which matches users with projects they have access to and lastly, what is most complicated for me newbie: c) a checkup function for each project (and subsequently, every object request for and object inside the project) whether the respective logged in user has access

if we want to be forward-looking, we could implement b) with the distinction of read/write access? hope i have expressed my agreement with your comment =)

[johnmartins]

We should discuss this in our next meeting! I lean more towards alternative 2 or some in-between solution, since other applications are likely to also want projects. If projects are defined in "core" then we wouldn't have to reinvent the wheel for each app. It's a good thing you brought this up, I think we need to think this through thoroughly

[inigoalonso]

Discussion 20210310: common project object for all apps, with the list of users, and their roles and access levels. So option 2 mentioned above.

[mujakob]

Julian realised "project" in core, linking EF-M to it project is still under edit though

[johnmartins]

No time allocated into implementation of EF-M into SED labs in the past year. Currently seems unlikely to be implemented as was originally envisioned. Cancelling issue.