[Kimchi-devel] RFC: Design of Authorization in Kimchi
Yu Xin Huo
huoyuxin at linux.vnet.ibm.com
Tue Jul 8 10:00:02 UTC 2014
On 7/8/2014 4:01 AM, Aline Manera wrote:
>
>
> On 07/07/2014 07:35 AM, Aline Manera wrote:
>>
>>
>> On 07/07/2014 06:45 AM, Wen Wang wrote:
>>> Hi all,
>>>
>>> Due to the fact that Kimchi needs authorization feature to be designed.
>>> I an posting my point of view below of how I thought about doing it,
>>> including how I plan doing it in the front-end and request for help for
>>> the back end support.
>>>
>>> Kimchi changed to a traditional login patten in last release that makes
>>> Kimchi more secure to use. It Before login, the front-end can hardly
>>> get
>>> any html information before user actually login.
>>
>> If the user is not logged in, Kimchi server will always return 401 for
>> all the requests.
>> As the front end make requests to server to populate the html, if the
>> user hardly gets any html he/she will get it empty without any useful
>> information
>> At least, it is suppose to work like that.
>>
>> As we discussed, root
>>> user will have full access to Kimchi whereas the non-root user will
>>> have
>>> restricted privileges. It will be easier and more decent to show the
>>> proper tabs to certain users that distinguished by the back-end. Now
>>> the
>>> tabs are generated by an xml file generated from the back-end that show
>>> all 5 tabs. We probably need to have the '*Host*' and '*template*'
>>> tab_removed_ for non-root users, which is recommended to be done in the
>>> back-end.
>>
>> I suggest to add one parameter to the tabs in the xml.
>>
>> Example: access="restricted" which means only root users can see
>> those tabs
>>
>> And in the front end while loading the tabs, we need to query this
>> parameter and act accordingly (ie, do not display the tab with this
>> parameter for a non-root user)
>>
>> <tabs>
>> <tab access="restricted">
>> <title>Host</title>
>> <path>tabs/host.html>
>> </tab>
>> <tab>
>> <title>Guests</title>
>> <path>tabs/guests.html>
>> </tab>
>> ...
>> </tabs>
>>
>
> I've just thought more about that and maybe it won't be enough
> Probably, for each tab we should describe which view display according
> to user role
>
> <tab>
> <title>Host</title>
> <path>tabs/host.html>
> <views>
> <view role="admin" mode="full" />
> <view role="user" mode="none" />
> </views>
> </tab>
>
> For "mode" we can have:
> - full: full access to tab content
> - none: tab should not be displayed
> - resource: user can manage the resource he/she is assigned to but not
> create a new one
> - read-only: user can see the resources but not manage them or create
> a new one
>
> And in the /login request we return a list of user roles
>
> {
> username: alinefm,
> roles: [admin]
> groups: [group1, group2]
> }
>
> For now, only one value will be returned for "roles" but later one
> user can have multiples roles: vm-user, network-admin, etc
>
>
For sprint 1, if a VM assigned to a user, this user will have full
access to VM, so we need to handle below at client side,
1. identify whether a user have access to a certain tab, non-root access
'Guest', 'Network', 'Storage'
2. identify the actions that a user can perform in a tab, non-root,
admin to 'Guest', read-only to 'Storage' and 'Network'.
So for sprint 1, design below:
<tab access-level="*none*"> -- do not show the tab
<title>Host</title>
<path>tabs/host.html>
</tab>
<tab access-level="*admin*"> -- full access including
'edit/delete/start/stop/use'
<title>Host</title>
<path>tabs/host.html>
</tab>
<tab access-level="*user*"> -- read-only access including
'start/stop/use'
<title>Host</title>
<path>tabs/host.html>
</tab>
For the whole release, we have that, assign user to a VM with 'admin' or
'user' role.
so we need to handle that, for a list of VMs, some VMs, user have full
access, and some are read-only, this need to be handled by instance.
so design below:
<tab access-level="*none*"> -- do not show the tab
<title>Host</title>
<path>tabs/host.html>
</tab>
<tab access-level="*admin*"> -- full access including
'edit/delete/start/stop/use'
<title>Host</title>
<path>tabs/host.html>
</tab>
<tab access-level="*user*"> -- read-only access including
'start/stop/use'
<title>Host</title>
<path>tabs/host.html>
</tab>
<tab access-level="*byInstance*"> -- a list of instances, each
instance will have access-level for the user like 'admin' or 'user' role
on a certain VM.
<title>Host</title>
<path>tabs/host.html>
</tab>
>>>
>>> Also there need to be information provided to the front-end like the
>>> user-name, user-role as well as user-group, etc. that indicate user
>>> identity after login.
>>
>>
>> The browser need the information to give certain
>>> privileges to certain users and disable the unnecessary functions. My
>>> suggestion is to have these 3 parameters passed: ***user-name,
>>> user-role* as well as *user-group*. There is a better extendibility to
>>> user the user-role other than isRoot so that we can define more
>>> roles in
>>> the future. As fact that we have only defined two roles now, the
>>> user-role parameter can be divided into root and guest based on user is
>>> root or non-root.
>>
>> Today that information is returned as response for the request /login
>>
>> POST /login {username: alinefm, password: mypassword}
>> {
>> username: alinefm,
>> sudo: true,
>> groups: [group1, group2]
>> }
>>
>> If "sudo" is true, the user has root permissions, otherwise it is a
>> non-root user.
>>
>> Based on that you said, I propose to change the "sudo" parameter to
>> "role" and it the user has root permissions we set it to "admin",
>> otherwise, "user"
>>
>> POST /login {username: alinefm, password: mypassword}
>> {
>> username: alinefm,
>> role: admin,
>> groups: [group1, group2]
>> }
>>
>>
>> These message can get from *sessiondada*, *cookie *or
>>> passed according to a query. the way passing the info of the user is
>>> still under discussion.
>>
>> As you will get that info after a login request I propose to store that
>> info locally on JS
>>
>>
>> Request for your advises.
>>>
>>> Best Regards
>>>
>>> Wang Wen
>>>
>>>
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140708/557f4ed8/attachment.html>
More information about the Kimchi-devel
mailing list