[Wok] Do not link user role with UI tabs

Hi all, Today, Wok provides basic authorization level for all the application. When using PAM authentication, an user with root right (sudo ALL) will be considered a sysadmin and will have full control no Wok and its plugins. When using LDAP authentication, the users listed in "admin_users" parameter in wok.conf will be considered a sysadmin and then having full control on Wok and its plugins. Thinking about providing more granularity on authorization (ie, grant access to a normal user to create a VM on Kimchi, for example) the user role (sysadmin or normal user) was linked to the UI tabs (:-() instead of the API itself (you can see it on src/wok/auth.py) It can cause multiple issues, for example: - different plugins with the same tab name (the case of Ginger and Kimchi) will get the authorization settings merged - what about a tab making using of different APIs? The case of "Administration" tab on Ginger So, IMO the better solution would be to have that granularity (when it will be implemented) by API. So when a sysadmin may want to grant permission to a normal user to manage virtual machines, there would be an API like: POST /config/permission {api: <api>, username: <username>, role: admin|user} That will store the information in a DB (objectstore) and make use of it when responding to a request. with objectstore as session: user_role = session.get('permission', <api>, <username>) The reason of this RFC is to change the USER_ROLES we have today in auth.py to only store if the user is an admin or not and make use of it in the whole application not linked to any tab. That means, all the self.role_key parameter will be removed and the UI will be changed as well to reflect that. What do you think about it? I plan to send a patch to remove the link between user role and tabs as soon as we get agreement on it and the patches about grant permissions will require more discussions. Regards, Aline Manera

On 18/01/2017 10:51, Aline Manera wrote:
Hi all,
Today, Wok provides basic authorization level for all the application. When using PAM authentication, an user with root right (sudo ALL) will be considered a sysadmin and will have full control no Wok and its plugins. When using LDAP authentication, the users listed in "admin_users" parameter in wok.conf will be considered a sysadmin and then having full control on Wok and its plugins.
Thinking about providing more granularity on authorization (ie, grant access to a normal user to create a VM on Kimchi, for example) the user role (sysadmin or normal user) was linked to the UI tabs (:-() instead of the API itself (you can see it on src/wok/auth.py)
It can cause multiple issues, for example: - different plugins with the same tab name (the case of Ginger and Kimchi) will get the authorization settings merged - what about a tab making using of different APIs? The case of "Administration" tab on Ginger
So, IMO the better solution would be to have that granularity (when it will be implemented) by API.
So when a sysadmin may want to grant permission to a normal user to manage virtual machines, there would be an API like:
POST /config/permission {api: <api>, username: <username>, role: admin|user}
That will store the information in a DB (objectstore) and make use of it when responding to a request.
with objectstore as session: user_role = session.get('permission', <api>, <username>)
The reason of this RFC is to change the USER_ROLES we have today in auth.py to only store if the user is an admin or not and make use of it in the whole application not linked to any tab. That means, all the self.role_key parameter will be removed and the UI will be changed as well to reflect that.
What do you think about it?
I plan to send a patch to remove the link between user role and tabs as soon as we get agreement on it and the patches about grant permissions will require more discussions.
Regards, Aline Manera
That's a good approach IMO. We could leverage the opportunity to add a PAM-specific configuration to wok for restricting access for only those users in group "wok" (not all users in that system may be allowed to access wok). This is also a debian requirement for packaging and was implemented by this patch: https://github.com/lcorreia/wok/commit/9de9856188c2e826ddc90a07f549c7c7972f9... along with a wok-specific pam config file, like this: https://github.com/lcorreia/wok/blob/lcorreia/debianization-2.3.1/debian/wok... Regards, -- Lucio Correia

On 01/18/2017 10:51 AM, Aline Manera wrote:
Hi all,
Today, Wok provides basic authorization level for all the application. When using PAM authentication, an user with root right (sudo ALL) will be considered a sysadmin and will have full control no Wok and its plugins. When using LDAP authentication, the users listed in "admin_users" parameter in wok.conf will be considered a sysadmin and then having full control on Wok and its plugins.
Thinking about providing more granularity on authorization (ie, grant access to a normal user to create a VM on Kimchi, for example) the user role (sysadmin or normal user) was linked to the UI tabs (:-() instead of the API itself (you can see it on src/wok/auth.py)
It can cause multiple issues, for example: - different plugins with the same tab name (the case of Ginger and Kimchi) will get the authorization settings merged - what about a tab making using of different APIs? The case of "Administration" tab on Ginger
So, IMO the better solution would be to have that granularity (when it will be implemented) by API.
So when a sysadmin may want to grant permission to a normal user to manage virtual machines, there would be an API like:
POST /config/permission {api: <api>, username: <username>, role: admin|user}
That will store the information in a DB (objectstore) and make use of it when responding to a request.
with objectstore as session: user_role = session.get('permission', <api>, <username>)
The reason of this RFC is to change the USER_ROLES we have today in auth.py to only store if the user is an admin or not and make use of it in the whole application not linked to any tab. That means, all the self.role_key parameter will be removed and the UI will be changed as well to reflect that.
What do you think about it?
I plan to send a patch to remove the link between user role and tabs as soon as we get agreement on it and the patches about grant permissions will require more discussions.
+1
Regards, Aline Manera
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Aline Manera
-
Daniel Henrique Barboza
-
Lucio Correia