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

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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel >