RFC: Design of Authorization in Kimchi
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. 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. 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. 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. Request for your advises. Best Regards Wang Wen
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>
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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/08/2014 04: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
It is nice that we add the role attributes that well indicate the right authorization, benefit from which the browser can provide the proper privileges to certain users. However we have the role already and according to which we can easily define the mode by user. By this means we probably won't need the mode attribute since the browser can assign different function according to role. Though we can difine more role that fulfil different modes like admin can have "full" access and user should have the role discribed as "none". It's good point.
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
Storing it in JS as a variable is fine, according to which, the back-end should apply the API as you discribed above which browser can query everytime it's needed. We have to take user refreshing the page into consideration. Or else, we can store it into sessionstorage which has the similar function as cookie in HTML5. I recommend the second solution since it reduced the effort that request for role and username everytime we need to have the page refreshed. Best Regards Wang Wen
Request for your advises.
Best Regards
Wang Wen
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/08/2014 01:16 PM, Wen Wang wrote:
On 07/08/2014 04: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
It is nice that we add the role attributes that well indicate the right authorization, benefit from which the browser can provide the proper privileges to certain users. However we have the role already and according to which we can easily define the mode by user. By this means we probably won't need the mode attribute since the browser can assign different function according to role.
Though we can difine more role that fulfil different modes like admin can have "full" access and user should have the role discribed as "none". It's good point.
Talked to Yu Xin, and we figured out your mode design is pretty brilliant for adding the mode attribute. According to which I think we can accomplish assigning different privileges by an easier way. Here is my thought: The front-end need only mode attribute that indicate which tab as well as action a user can do. Take the following script for example: <tab *mode="none"*> <title>Host</tittle> <path>tabs/host.html</path> </tab> <tab *mode="full"*> <title>Guests</title> <path>tabs/guests.html</path> </tabs> <tab *mode="readonly"*> <title>Network</title> <path>tabs/network.html</path> </tabs> Browser should know the "Host" tab should not be displayed, user should have full access to "Guests" and "Network" tab should only be displayed but not avaliable for editing. The role should be defined in the back-end to indicate different roles have different access to different tabs as well as actions. Modes are assigned to the tabs and all instances under that tab inherit the same mode. Server filter which mode should a user have in the back-end. User role change might be enabled in the future and server should have the user role changed in the back-end and return right mode to the browser. Or I have another thought is a fine grained design also inspired by your mode pattern. Mode is defined by instance. The back-end should store the mode for each instance. For example, one user have 10 VMs and have full access for 3 of them including editing but only vnc connect for 7 of them. There should be another level of mode defined to the instance under each table. It could probably but not necessarily be like this : - master: Full access to the instance - authroized: Full access except for create/delete - usable: Only connection is allowed(For VMs' concern) - display: readonly Request for your comment Best Regards Wang Wen
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
Storing it in JS as a variable is fine, according to which, the back-end should apply the API as you discribed above which browser can query everytime it's needed. We have to take user refreshing the page into consideration. Or else, we can store it into sessionstorage which has the similar function as cookie in HTML5.
I recommend the second solution since it reduced the effort that request for role and username everytime we need to have the page refreshed.
Best Regards
Wang Wen
Request for your advises.
Best Regards
Wang Wen
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
ACK, thanks Aline, I think this will work. On 07/09/2014 12:13 AM, Aline Manera wrote:
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Aline Manera -
Wen Wang -
Yu Xin Huo