[Kimchi-devel] RFC: Design of Authorization in Kimchi

[Wen Wang]

On 07/08/2014 04: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
It is nice that we add the role attributes that well indicate the right 
authorization, benefit from which the browser can provide the proper 
privileges to certain users. However we have the role already and 
according to which we can easily define the mode by user. By this means 
we probably won't need the mode attribute since the browser can assign 
different function according to role.

Though we can difine more role that fulfil different modes like admin 
can have "full" access and user should have the role discribed as 
"none". It's good point.
>
> 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
>
>
>>>
>>> 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
Storing it in JS as a variable is fine, according to which, the back-end 
should apply the API as you discribed above which browser can query 
everytime it's needed. We have to take user refreshing the page into 
consideration. Or else, we can store it into sessionstorage which has 
the similar function as cookie in HTML5.

I recommend the second solution since it reduced the effort that request 
for role and username everytime we need to have the page refreshed.

Best Regards

Wang Wen
>>
>>
>> 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
>>