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

[Aline Manera]

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


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