From alinefm at linux.vnet.ibm.com Mon Jul 7 16:01:14 2014 Content-Type: multipart/mixed; boundary="===============3120386093883039503==" MIME-Version: 1.0 From: Aline Manera To: kimchi-devel at ovirt.org Subject: Re: [Kimchi-devel] RFC: Design of Authorization in Kimchi Date: Mon, 07 Jul 2014 17:01:05 -0300 Message-ID: <53BAFC81.2090704@linux.vnet.ibm.com> In-Reply-To: 53BA780F.6020907@linux.vnet.ibm.com --===============3120386093883039503== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=3D"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) > > > > Host > tabs/host.html> > > > Guests > tabs/guests.html> > > ... > > 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 Host tabs/host.html> 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 > --===============3120386093883039503==--