<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 07/08/2014 01:16 PM, Wen Wang wrote:<br>
</div>
<blockquote cite="mid:53BB7EAD.6000701@linux.vnet.ibm.com"
type="cite">
<br>
On 07/08/2014 04:01 AM, Aline Manera wrote:
<br>
<blockquote 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>
</blockquote>
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.
<br>
<br>
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. <br>
</blockquote>
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:<br>
<br>
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:<br>
<br>
<tab <b>mode="none"</b>><br>
<title>Host</tittle><br>
<path>tabs/host.html</path><br>
</tab><br>
<br>
<tab <b>mode="full"</b>><br>
<title>Guests</title><br>
<path>tabs/guests.html</path><br>
</tabs><br>
<br>
<tab <b>mode="readonly"</b>><br>
<title>Network</title><br>
<path>tabs/network.html</path><br>
</tabs><br>
<br>
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. <br>
<br>
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 :<br>
<br>
- master: Full access to the instance<br>
- authroized: Full access except for create/delete<br>
- usable: Only connection is allowed(For VMs' concern)<br>
- display: readonly<br>
<br>
Request for your comment<br>
<br>
Best Regards<br>
<br>
Wang Wen<br>
<blockquote cite="mid:53BB7EAD.6000701@linux.vnet.ibm.com"
type="cite">
<blockquote type="cite">
<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 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>
</blockquote>
</blockquote>
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.
<br>
<br>
I recommend the second solution since it reduced the effort that
request for role and username everytime we need to have the page
refreshed.
<br>
<br>
Best Regards
<br>
<br>
Wang Wen
<br>
<blockquote type="cite">
<blockquote type="cite">
<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>
</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>