<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 7/8/2014 4:01 AM, Aline Manera
wrote:<br>
</div>
<blockquote cite="mid:53BAFC81.2090704@linux.vnet.ibm.com"
type="cite">
<br>
<br>
On 07/07/2014 07:35 AM, Aline Manera wrote:
<br>
<blockquote type="cite">
<br>
<br>
On 07/07/2014 06:45 AM, Wen Wang wrote:
<br>
<blockquote type="cite">Hi all,
<br>
<br>
Due to the fact that Kimchi needs authorization feature to be
designed.
<br>
I an posting my point of view below of how I thought about
doing it,
<br>
including how I plan doing it in the front-end and request for
help for
<br>
the back end support.
<br>
<br>
Kimchi changed to a traditional login patten in last release
that makes
<br>
Kimchi more secure to use. It Before login, the front-end can
hardly get
<br>
any html information before user actually login.
<br>
</blockquote>
<br>
If the user is not logged in, Kimchi server will always return
401 for
<br>
all the requests.
<br>
As the front end make requests to server to populate the html,
if the
<br>
user hardly gets any html he/she will get it empty without any
useful
<br>
information
<br>
At least, it is suppose to work like that.
<br>
<br>
As we discussed, root
<br>
<blockquote type="cite">user will have full access to Kimchi
whereas the non-root user will have
<br>
restricted privileges. It will be easier and more decent to
show the
<br>
proper tabs to certain users that distinguished by the
back-end. Now the
<br>
tabs are generated by an xml file generated from the back-end
that show
<br>
all 5 tabs. We probably need to have the '*Host*' and
'*template*'
<br>
tab_removed_ for non-root users, which is recommended to be
done in the
<br>
back-end.
<br>
</blockquote>
<br>
I suggest to add one parameter to the tabs in the xml.
<br>
<br>
Example: access="restricted" which means only root users can see
those tabs
<br>
<br>
And in the front end while loading the tabs, we need to query
this
<br>
parameter and act accordingly (ie, do not display the tab with
this
<br>
parameter for a non-root user)
<br>
<br>
<tabs>
<br>
<tab access="restricted">
<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<tab>
<br>
<title>Guests</title>
<br>
<path>tabs/guests.html>
<br>
</tab>
<br>
...
<br>
</tabs>
<br>
<br>
</blockquote>
<br>
I've just thought more about that and maybe it won't be enough
<br>
Probably, for each tab we should describe which view display
according to user role
<br>
<br>
<tab>
<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
<views>
<br>
<view role="admin" mode="full" />
<br>
<view role="user" mode="none" />
<br>
</views>
<br>
</tab>
<br>
<br>
For "mode" we can have:
<br>
- full: full access to tab content
<br>
- none: tab should not be displayed
<br>
- resource: user can manage the resource he/she is assigned to but
not create a new one
<br>
- read-only: user can see the resources but not manage them or
create a new one
<br>
<br>
And in the /login request we return a list of user roles
<br>
<br>
{
<br>
username: alinefm,
<br>
roles: [admin]
<br>
groups: [group1, group2]
<br>
}
<br>
<br>
For now, only one value will be returned for "roles" but later one
user can have multiples roles: vm-user, network-admin, etc
<br>
<br>
<br>
</blockquote>
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,<br>
1. identify whether a user have access to a certain tab, non-root
access 'Guest', 'Network', 'Storage'<br>
2. identify the actions that a user can perform in a tab, non-root,
admin to 'Guest', read-only to 'Storage' and 'Network'.<br>
So for sprint 1, design below:<br>
<tab access-level="<b>none</b>">
-- do not show the tab<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<tab access-level="<b>admin</b>"> -- full access
including 'edit/delete/start/stop/use'<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<tab access-level="<b>user</b>">
-- read-only access including 'start/stop/use'<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<br>
For the whole release, we have that, assign user to a VM with
'admin' or 'user' role. <br>
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. <br>
so design below:<br>
<tab access-level="<b>none</b>">
-- do not show the tab<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<tab access-level="<b>admin</b>"> -- full access
including 'edit/delete/start/stop/use'<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<tab access-level="<b>user</b>">
-- read-only access including 'start/stop/use'<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<tab access-level="<b>byInstance</b>">
-- a list of instances, each instance will have access-level for the
user like 'admin' or 'user' role on a certain VM.<br>
<title>Host</title>
<br>
<path>tabs/host.html>
<br>
</tab>
<br>
<br>
<blockquote cite="mid:53BAFC81.2090704@linux.vnet.ibm.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
Also there need to be information provided to the front-end
like the
<br>
user-name, user-role as well as user-group, etc. that indicate
user
<br>
identity after login.
<br>
</blockquote>
<br>
<br>
The browser need the information to give certain
<br>
<blockquote type="cite">privileges to certain users and disable
the unnecessary functions. My
<br>
suggestion is to have these 3 parameters passed: ***user-name,
<br>
user-role* as well as *user-group*. There is a better
extendibility to
<br>
user the user-role other than isRoot so that we can define
more roles in
<br>
the future. As fact that we have only defined two roles now,
the
<br>
user-role parameter can be divided into root and guest based
on user is
<br>
root or non-root.
<br>
</blockquote>
<br>
Today that information is returned as response for the request
/login
<br>
<br>
POST /login {username: alinefm, password: mypassword}
<br>
{
<br>
username: alinefm,
<br>
sudo: true,
<br>
groups: [group1, group2]
<br>
}
<br>
<br>
If "sudo" is true, the user has root permissions, otherwise it
is a
<br>
non-root user.
<br>
<br>
Based on that you said, I propose to change the "sudo" parameter
to
<br>
"role" and it the user has root permissions we set it to
"admin",
<br>
otherwise, "user"
<br>
<br>
POST /login {username: alinefm, password: mypassword}
<br>
{
<br>
username: alinefm,
<br>
role: admin,
<br>
groups: [group1, group2]
<br>
}
<br>
<br>
<br>
These message can get from *sessiondada*, *cookie *or
<br>
<blockquote type="cite">passed according to a query. the way
passing the info of the user is
<br>
still under discussion.
<br>
</blockquote>
<br>
As you will get that info after a login request I propose to
store that
<br>
info locally on JS
<br>
<br>
<br>
Request for your advises.
<br>
<blockquote type="cite">
<br>
Best Regards
<br>
<br>
Wang Wen
<br>
<br>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>