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.

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.

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.

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.

passed according to a query. the way passing the info of the user is still under discussion.

Best Regards Wang Wen _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

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 >

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

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