Allow current user to do more with the Magpie API

[dbyrns]

Currently some GET are available to the current user without admin privileges, but most of the functions required admin privileges.
We should make an exhaustive list of what a user could do without elevated permissions but rapidly these are some of them:

• Update the current user info (possible as of Magpie 2.0, see Milestone 2.0 - User scope views, Discoverable Groups & Patches #340)
• Delete the current user
• Update / Delete group for which the current user has permissions (edit: possible via discoverable groups)
• Add / Remove a user to a group for which the current user has permissions
• Add / Remove resources to a service for which the current user has permissions
• Add / Remove user's permissions to a resource part of a service for which the current user has permissions

Now we see the needs to assign permissions over groups and services (obviously we have the permissions over ourselves (user)).

Using #169, Magpie could be used itself to edit these permissions.

[fmigneault]

Updating user info implies the ability of updating its groups.
So anyone could login with their user no matter the permission they have, and give themselves the admin permission...

[dbyrns]

I though that updating user info means changing password, name and email as state here : https://geoimagenet.crim.ca/magpie/api#/Logged%20User/put_users_current

Indeed a user should only be able to assign itself (or other users) to groups for which it has already permissions. If I don't have permissions on the admin group I cannot put myself nor anybody else in that group. However, if an admin gives me permissions over the admin group then I should be able to add myself to that group and anybody I want to.

[dbyrns]

And please note the subtle difference between being part of a group vs having permissions on a group. I would not grant permissions on a group for all users part of that group.

[fmigneault]

@dbyrns
You're right about the update of user info. My bad.

I think the term "permission" is confusing in this case. Are you referring to "roles"?
By this, I mean allowed operations/requests to Magpie API to change its behavior rather than user/group/service/resource permissions managed by Mapgie.

Current Magpie has 2 "roles":

• "admin" - full access
• "anonymous" - routes not marked admin only

So to clarify, we would have a ServiceRole (or whatever) that allows you to set GET/POST/PUT/... as allowed operations for user "x" or group "y". And instead of checking for admin/anonymous access, we would validate against the user/group/role matrix?

[dbyrns]

By permission I always mean what is managed by Magpie via the checkbox matrix.
I think that your conclusion is the good one (we need 3 roles):

• anonymous - Keep the current behavior
• admin - Should be limited to the strict minimum requests that are really related to admin
• managed - Role that are managed by the permissions matrix

I call your ServiceRole managed, because it's short and indicate that this role is managed somehow. Still open to better alternative.

[fmigneault]

@dbyrns I like the managed naming 👍