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