[Kimchi-devel] [Wok] Do not link user role with UI tabs

[Daniel Henrique Barboza]

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