[Kimchi-devel] RFC: Design of Authorization in Kimchi
Wen Wang
wenwang at linux.vnet.ibm.com
Wed Jul 9 02:07:44 UTC 2014
ACK, thanks Aline, I think this will work.
On 07/09/2014 12:13 AM, Aline Manera wrote:
>
> Thanks, Wen Wang and Yu Xin for the replies!
> I guess we get an agreement on that :-)
>
> So the "mode"/"access-level" attribute will be only used when the user
> has a "user" role, and ignored when the user has "admin" role - as
> he/she will have full access to kimchi. Right?
>
> About the mode values:
> - none: do not show the tab
> - admin: full access including 'edit/delete/start/stop/use'
> - read-only: read-only access including 'start/stop/use'
> - byInstance: each resource will have its configuration sent by the
> backend (JSON)
>
> For now, we will have:
> - host tab: none
> - template tab: none
> - network tab: read-only
> - storage tab: read-only
> - guest tab: admin
>
> Remembering the "admin" mode in the guest tab does not allow a user to
> create a new vm, ok?
>
> And for the /login API we will have the "roles" parameter (replacing
> the "sudo" parameter) that has 2 valid values by now: admin or user
>
> {
> ...
> roles: [admin|user]
> }
>
> About how store that data in the front end, I am OK in using
> sessionstorage or cookie as Wen Wang proposed.
>
> ACK?
>
> If so, I can work in the backend patches.
>
>
> On 07/08/2014 07:00 AM, Yu Xin Huo wrote:
>> 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
>>>
>>
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
More information about the Kimchi-devel
mailing list