From alinefm at linux.vnet.ibm.com Tue Jul 8 12:13:51 2014 Content-Type: multipart/mixed; boundary="===============3896791988218879522==" MIME-Version: 1.0 From: Aline Manera To: kimchi-devel at ovirt.org Subject: Re: [Kimchi-devel] RFC: Design of Authorization in Kimchi Date: Tue, 08 Jul 2014 13:13:10 -0300 Message-ID: <53BC1896.5040102@linux.vnet.ibm.com> In-Reply-To: 53BBC122.8050602@linux.vnet.ibm.com --===============3896791988218879522== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks, Wen Wang and Yu Xin for the replies! I guess we get an agreement on that :-) So the "mode"/"access-level" attribute will be only used when the user = has a "user" role, and ignored when the user has "admin" role - as = he/she will have full access to kimchi. Right? About the mode values: - none: do not show the tab - admin: full access including 'edit/delete/start/stop/use' - read-only: read-only access including 'start/stop/use' - byInstance: each resource will have its configuration sent by the = backend (JSON) For now, we will have: - host tab: none - template tab: none - network tab: read-only - storage tab: read-only - guest tab: admin Remembering the "admin" mode in the guest tab does not allow a user to = create a new vm, ok? And for the /login API we will have the "roles" parameter (replacing the = "sudo" parameter) that has 2 valid values by now: admin or user { ... roles: [admin|user] } About how store that data in the front end, I am OK in using = sessionstorage or cookie as Wen Wang proposed. ACK? If so, I can work in the backend patches. On 07/08/2014 07:00 AM, Yu Xin Huo wrote: > 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=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 >> >> > 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: > -- do not show the tab > Host > tabs/host.html> > > -- full access including > 'edit/delete/start/stop/use' > Host > tabs/host.html> > > -- read-only access including > 'start/stop/use' > Host > tabs/host.html> > > > 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: > -- do not show the tab > Host > tabs/host.html> > > -- full access including > 'edit/delete/start/stop/use' > Host > tabs/host.html> > > -- read-only access including > 'start/stop/use' > Host > tabs/host.html> > > -- a list of instances, each > instance will have access-level for the user like 'admin' or 'user' role > on a certain VM. > Host > tabs/host.html> > > >>>> >>>> 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 > --===============3896791988218879522==--