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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel