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

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