9:16 p.m.
From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
This patchset provides the backend changes discussed in "[Kimchi-devel] RFC: Design
of Authorization in Kimchi"
Aline Manera (2):
authorization: Update /login to return user roles instead of sudo
parameter
authorization: Add "mode" attribute to describe user view
config/ui/tabs.xml | 10 +++++-----
src/kimchi/auth.py | 12 ++++++++----
tests/test_rest.py | 6 ++++++
tests/utils.py | 6 +++---
4 files changed, 22 insertions(+), 12 deletions(-)
--
1.9.3
9:16 p.m.
New subject: [PATCH 1/2] authorization: Update /login to return user roles instead of sudo parameter
From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
For now, Kimchi just supports 2 types of user roles: 'admin' - user has
full control of Kimchi features and 'user' with limited access. But in
future the idea is to have more and more roles so it is good to
already provide the authorization support with that in mind.
That way, instead of only returning if user has or not sudo permissions, the
/login API will return the user roles.
If the user has sudo permissions he/she will have 'admin' role,
otherwise, 'user' role.
curl -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/login
-d'{"username": "guest", "password":
"guest-passwd"}' -X POST
{"username": "guest", "roles": ["user"],
"groups": []}
curl -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/login
-d'{"username": "sysadmin", "password":
"sysadmin-passwd"}' -X POST
{"username": "sysadmin", "roles": ["admin"],
"groups": []}
Signed-off-by: Aline Manera <alinefm(a)linux.vnet.ibm.com>
---
src/kimchi/auth.py | 12 ++++++++----
tests/test_rest.py | 6 ++++++
tests/utils.py | 6 +++---
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/src/kimchi/auth.py b/src/kimchi/auth.py
index 6a4a610..b1febf0 100644
--- a/src/kimchi/auth.py
+++ b/src/kimchi/auth.py
@@ -38,6 +38,7 @@
USER_NAME = 'username'
USER_GROUPS = 'groups'
USER_SUDO = 'sudo'
+USER_ROLES = 'roles'
REFRESH = 'robot-refresh'
@@ -62,7 +63,7 @@ def __init__(self, username):
self.user = {}
self.user[USER_NAME] = username
self.user[USER_GROUPS] = None
- self.user[USER_SUDO] = False
+ self.user[USER_ROLES] = ['user']
def get_groups(self):
self.user[USER_GROUPS] = [g.gr_name for g in grp.getgrall()
@@ -74,10 +75,13 @@ def has_sudo(self):
p = multiprocessing.Process(target=self._has_sudo, args=(result,))
p.start()
p.join()
- self.user[USER_SUDO] = bool(result.value)
- return self.user[USER_SUDO]
+ if result.value:
+ self.user[USER_ROLES] = ['admin']
+ return result.value
def _has_sudo(self, result):
+ result.value = False
+
_master, slave = pty.openpty()
os.setsid()
fcntl.ioctl(slave, termios.TIOCSCTTY, 0)
@@ -94,7 +98,7 @@ def _has_sudo(self, result):
self.user[USER_NAME]])
for line in out.split('\n'):
if line and re.search("(ALL)", line):
- result.value = 1
+ result.value = True
debug("User %s can run any command with sudo" %
result.value)
return
diff --git a/tests/test_rest.py b/tests/test_rest.py
index ad8fc72..ba9431d 100644
--- a/tests/test_rest.py
+++ b/tests/test_rest.py
@@ -1552,6 +1552,12 @@ def test_auth_session(self):
req = json.dumps({'username': user, 'password': pw})
resp = self.request('/login', req, 'POST', hdrs)
self.assertEquals(200, resp.status)
+
+ user_info = json.loads(resp.read())
+ self.assertEquals(sorted(user_info.keys()),
+ ['groups', 'roles', 'username'])
+ self.assertEquals(user_info['roles'], [u'admin'])
+
cookie = resp.getheader('set-cookie')
hdrs['Cookie'] = cookie
diff --git a/tests/utils.py b/tests/utils.py
index fd9b23c..4853b7a 100644
--- a/tests/utils.py
+++ b/tests/utils.py
@@ -157,8 +157,8 @@ def patch_auth(sudo=True):
def _get_groups(self):
return None
- def _has_sudo(self):
- return sudo
+ def _has_sudo(self, result):
+ result.value = sudo
def _authenticate(username, password, service="passwd"):
try:
@@ -170,7 +170,7 @@ def _authenticate(username, password, service="passwd"):
import kimchi.auth
kimchi.auth.authenticate = _authenticate
kimchi.auth.User.get_groups = _get_groups
- kimchi.auth.User.has_sudo = _has_sudo
+ kimchi.auth.User._has_sudo = _has_sudo
def normalize_xml(xml_str):
--
1.9.3
6:40 a.m.
New subject: [PATCH 1/2] authorization: Update /login to return user roles instead of sudo parameter
The login pattern has been changed to the traditional login page which
the "username" and the "password" will be submitted using form.
However
the "/login" api is used in the login_window pattern that we no longer
use. When using the "/login", browser get a "303" and redirect the
page
to |https://9.123.141.135:8001/#tabs/guests.
from my point of view, I suppose we build another API that supplies the
"GET" method for the browser to get the username and role. Or else pass
the "username" and "role" through xml to have it stored into
sessionstorage or cookie.
For the roles, I recommend we have at least four for this release:
*admin*, *by-instance*, *read-only*, *none*. It's the by-instance mode I
have to explain.
from the diagram, tab mode is used for xml transfering which tab is
going to be displayed by user role. Take "Guest" tab for example, not
only do we need to show the tab, but also we need to know the user's
role so that we can display the proper vms. Different users need
different privilege for action. admin has full access, guest might be
divided into two roles: one is common users we give the user the ability
to start/stop/delete the vms that belongs to him, the other one might be
admin-user who is able to have the whole access to the action tab. To
clarify that, we need the by-instance tab. and the sub-tab.
Waiting for your comments
Best Regards
Wang Wen
|On 7/11/2014 10:16 AM, alinefm(a)linux.vnet.ibm.com wrote:
From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
For now, Kimchi just supports 2 types of user roles: 'admin' - user has
full control of Kimchi features and 'user' with limited access. But in
future the idea is to have more and more roles so it is good to
already provide the authorization support with that in mind.
That way, instead of only returning if user has or not sudo permissions, the
/login API will return the user roles.
If the user has sudo permissions he/she will have 'admin' role,
otherwise, 'user' role.
curl -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/login
-d'{"username": "guest", "password":
"guest-passwd"}' -X POST
{"username": "guest", "roles": ["user"],
"groups": []}
curl -H "Content-Type: application/json" -H "Accept:
application/json"
http://localhost:8010/login
-d'{"username": "sysadmin", "password":
"sysadmin-passwd"}' -X POST
{"username": "sysadmin", "roles": ["admin"],
"groups": []}
Signed-off-by: Aline Manera <alinefm(a)linux.vnet.ibm.com>
---
src/kimchi/auth.py | 12 ++++++++----
tests/test_rest.py | 6 ++++++
tests/utils.py | 6 +++---
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/src/kimchi/auth.py b/src/kimchi/auth.py
index 6a4a610..b1febf0 100644
--- a/src/kimchi/auth.py
+++ b/src/kimchi/auth.py
@@ -38,6 +38,7 @@
USER_NAME = 'username'
USER_GROUPS = 'groups'
USER_SUDO = 'sudo'
+USER_ROLES = 'roles'
REFRESH = 'robot-refresh'
@@ -62,7 +63,7 @@ def __init__(self, username):
self.user = {}
self.user[USER_NAME] = username
self.user[USER_GROUPS] = None
- self.user[USER_SUDO] = False
+ self.user[USER_ROLES] = ['user']
def get_groups(self):
self.user[USER_GROUPS] = [g.gr_name for g in grp.getgrall()
@@ -74,10 +75,13 @@ def has_sudo(self):
p = multiprocessing.Process(target=self._has_sudo, args=(result,))
p.start()
p.join()
- self.user[USER_SUDO] = bool(result.value)
- return self.user[USER_SUDO]
+ if result.value:
+ self.user[USER_ROLES] = ['admin']
+ return result.value
def _has_sudo(self, result):
+ result.value = False
+
_master, slave = pty.openpty()
os.setsid()
fcntl.ioctl(slave, termios.TIOCSCTTY, 0)
@@ -94,7 +98,7 @@ def _has_sudo(self, result):
self.user[USER_NAME]])
for line in out.split('\n'):
if line and re.search("(ALL)", line):
- result.value = 1
+ result.value = True
debug("User %s can run any command with sudo" %
result.value)
return
diff --git a/tests/test_rest.py b/tests/test_rest.py
index ad8fc72..ba9431d 100644
--- a/tests/test_rest.py
+++ b/tests/test_rest.py
@@ -1552,6 +1552,12 @@ def test_auth_session(self):
req = json.dumps({'username': user, 'password': pw})
resp = self.request('/login', req, 'POST', hdrs)
self.assertEquals(200, resp.status)
+
+ user_info = json.loads(resp.read())
+ self.assertEquals(sorted(user_info.keys()),
+ ['groups', 'roles', 'username'])
+ self.assertEquals(user_info['roles'], [u'admin'])
+
cookie = resp.getheader('set-cookie')
hdrs['Cookie'] = cookie
diff --git a/tests/utils.py b/tests/utils.py
index fd9b23c..4853b7a 100644
--- a/tests/utils.py
+++ b/tests/utils.py
@@ -157,8 +157,8 @@ def patch_auth(sudo=True):
def _get_groups(self):
return None
- def _has_sudo(self):
- return sudo
+ def _has_sudo(self, result):
+ result.value = sudo
def _authenticate(username, password, service="passwd"):
try:
@@ -170,7 +170,7 @@ def _authenticate(username, password, service="passwd"):
import kimchi.auth
kimchi.auth.authenticate = _authenticate
kimchi.auth.User.get_groups = _get_groups
- kimchi.auth.User.has_sudo = _has_sudo
+ kimchi.auth.User._has_sudo = _has_sudo
def normalize_xml(xml_str):
7:15 a.m.
New subject: [PATCH 1/2] authorization: Update /login to return user roles instead of sudo parameter
On 07/11/2014 08:40 AM, Wen Wang wrote:
The login pattern has been changed to the traditional login page
which
the "username" and the "password" will be submitted using form.
However
the "/login" api is used in the login_window pattern that we no longer
use. When using the "/login", browser get a "303" and redirect the
page
to |https://9.123.141.135:8001/#tabs/guests.
from my point of view, I suppose we build another API that supplies the
"GET" method for the browser to get the username and role. Or else pass
the "username" and "role" through xml to have it stored into
sessionstorage or cookie.
Got your point!
From backend code I have:
@cherrypy.expose
def login(self, *args, **kwargs):
...
auth.login(username, password, **kwa)
raise cherrypy.HTTPRedirect(next_url, 303)
I suggest we do the redirection in the front end after receiving the
login data
@cherrypy.expose
def login(self, *args, **kwargs):
...
return auth.login(username, password, **kwa)
And in UI get the data and redirect to right page
What do you think?
For the roles, I recommend we have at least four for this release:
*admin*, *by-instance*, *read-only*, *none*. It's the by-instance mode I
have to explain.
The roles for 1.3 will be "admin" and "user"
What you listed above are the "mode" attribute values
from the diagram, tab mode is used for xml transfering which tab is
going to be displayed by user role. Take "Guest" tab for example, not
only do we need to show the tab, but also we need to know the user's
role so that we can display the proper vms. Different users need
different privilege for action.
Related to the guest tab, if the user has access to a VM (ie, user is
assigned to that VM) he/she will have full control in the VM
admin has full access, guest might be
divided into two roles: one is common users we give the user the
ability
to start/stop/delete the vms that belongs to him, the other one might be
admin-user who is able to have the whole access to the action tab. To
clarify that, we need the by-instance tab. and the sub-tab.
Let me try to resume:
"admin" role in Guest tab can do everything: manage all VMs, create new
ones, etc
"user" role in Guest tab can manage all the VMs listed and CAN NOT
CREATE NEW ONE
We just need to care about those 2 roles right now
When we add more roles, we do the adjustments needed to accommodate them
Waiting for your comments
Best Regards
Wang Wen
|On 7/11/2014 10:16 AM, alinefm(a)linux.vnet.ibm.com wrote:
> From: Aline Manera<alinefm(a)linux.vnet.ibm.com>
>
> For now, Kimchi just supports 2 types of user roles: 'admin' - user has
> full control of Kimchi features and 'user' with limited access. But in
> future the idea is to have more and more roles so it is good to
> already provide the authorization support with that in mind.
> That way, instead of only returning if user has or not sudo permissions, the
> /login API will return the user roles.
> If the user has sudo permissions he/she will have 'admin' role,
> otherwise, 'user' role.
>
> curl -H "Content-Type: application/json" -H "Accept:
application/json"
> http://localhost:8010/login
> -d'{"username": "guest", "password":
"guest-passwd"}' -X POST
>
> {"username": "guest", "roles": ["user"],
"groups": []}
>
> curl -H "Content-Type: application/json" -H "Accept:
application/json"
> http://localhost:8010/login
> -d'{"username": "sysadmin", "password":
"sysadmin-passwd"}' -X POST
>
> {"username": "sysadmin", "roles": ["admin"],
"groups": []}
>
> Signed-off-by: Aline Manera<alinefm(a)linux.vnet.ibm.com>
> ---
> src/kimchi/auth.py | 12 ++++++++----
> tests/test_rest.py | 6 ++++++
> tests/utils.py | 6 +++---
> 3 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/src/kimchi/auth.py b/src/kimchi/auth.py
> index 6a4a610..b1febf0 100644
> --- a/src/kimchi/auth.py
> +++ b/src/kimchi/auth.py
> @@ -38,6 +38,7 @@
> USER_NAME = 'username'
> USER_GROUPS = 'groups'
> USER_SUDO = 'sudo'
> +USER_ROLES = 'roles'
> REFRESH = 'robot-refresh'
>
>
> @@ -62,7 +63,7 @@ def __init__(self, username):
> self.user = {}
> self.user[USER_NAME] = username
> self.user[USER_GROUPS] = None
> - self.user[USER_SUDO] = False
> + self.user[USER_ROLES] = ['user']
>
> def get_groups(self):
> self.user[USER_GROUPS] = [g.gr_name for g in grp.getgrall()
> @@ -74,10 +75,13 @@ def has_sudo(self):
> p = multiprocessing.Process(target=self._has_sudo, args=(result,))
> p.start()
> p.join()
> - self.user[USER_SUDO] = bool(result.value)
> - return self.user[USER_SUDO]
> + if result.value:
> + self.user[USER_ROLES] = ['admin']
> + return result.value
>
> def _has_sudo(self, result):
> + result.value = False
> +
> _master, slave = pty.openpty()
> os.setsid()
> fcntl.ioctl(slave, termios.TIOCSCTTY, 0)
> @@ -94,7 +98,7 @@ def _has_sudo(self, result):
> self.user[USER_NAME]])
> for line in out.split('\n'):
> if line and re.search("(ALL)", line):
> - result.value = 1
> + result.value = True
> debug("User %s can run any command with sudo" %
> result.value)
> return
> diff --git a/tests/test_rest.py b/tests/test_rest.py
> index ad8fc72..ba9431d 100644
> --- a/tests/test_rest.py
> +++ b/tests/test_rest.py
> @@ -1552,6 +1552,12 @@ def test_auth_session(self):
> req = json.dumps({'username': user, 'password': pw})
> resp = self.request('/login', req, 'POST', hdrs)
> self.assertEquals(200, resp.status)
> +
> + user_info = json.loads(resp.read())
> + self.assertEquals(sorted(user_info.keys()),
> + ['groups', 'roles', 'username'])
> + self.assertEquals(user_info['roles'], [u'admin'])
> +
> cookie = resp.getheader('set-cookie')
> hdrs['Cookie'] = cookie
>
> diff --git a/tests/utils.py b/tests/utils.py
> index fd9b23c..4853b7a 100644
> --- a/tests/utils.py
> +++ b/tests/utils.py
> @@ -157,8 +157,8 @@ def patch_auth(sudo=True):
> def _get_groups(self):
> return None
>
> - def _has_sudo(self):
> - return sudo
> + def _has_sudo(self, result):
> + result.value = sudo
>
> def _authenticate(username, password, service="passwd"):
> try:
> @@ -170,7 +170,7 @@ def _authenticate(username, password,
service="passwd"):
> import kimchi.auth
> kimchi.auth.authenticate = _authenticate
> kimchi.auth.User.get_groups = _get_groups
> - kimchi.auth.User.has_sudo = _has_sudo
> + kimchi.auth.User._has_sudo = _has_sudo
>
>
> def normalize_xml(xml_str):
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
9:16 p.m.
New subject: [PATCH 2/2] authorization: Add "mode" attribute to describe user view
From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
Kimchi has 2 user roles: "admin" with full control of Kimchi features
and "user" with limited access
To describe how each tab should be displayed for a user, the "mode"
attribute should be added.
The "mode" attribute values are:
- none: do not show the tab;
- admin: full instance access;
- read-only: read-only access;
- byInstance: each resource will have its configuration sent by the
backend;
The user will only be able to manage the guests he/she is assigned for,
because that the guest tab has 'mode' == admin
As a user can edit a guest, he/she may need to know which networks
and storage pools are configured, so set network and storage tab 'mode'
to read-only.
And as user should not perform any operation on host or templates, set
their 'mode' attributes to 'none'.
Signed-off-by: Aline Manera <alinefm(a)linux.vnet.ibm.com>
---
config/ui/tabs.xml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/config/ui/tabs.xml b/config/ui/tabs.xml
index b045521..b8e7bd6 100644
--- a/config/ui/tabs.xml
+++ b/config/ui/tabs.xml
@@ -1,22 +1,22 @@
<?xml version="1.0" encoding="utf-8"?>
<tabs>
- <tab>
+ <tab mode="none">
<title>Host</title>
<path>tabs/host.html</path>
</tab>
- <tab>
+ <tab mode="admin">
<title>Guests</title>
<path>tabs/guests.html</path>
</tab>
- <tab>
+ <tab mode="none">
<title>Templates</title>
<path>tabs/templates.html</path>
</tab>
- <tab>
+ <tab mode="read-only">
<title>Storage</title>
<path>tabs/storage.html</path>
</tab>
- <tab>
+ <tab mode="read-only">
<title>Network</title>
<path>tabs/network.html</path>
</tab>
--
1.9.3
1:31 a.m.
New subject: [PATCH 2/2] authorization: Add "mode" attribute to describe user view
Thanks Aline, I think there might be some issues by changing the xml
file manually. From the *tabs.xml* we get the mode that a user should
have but it doesn't change when we change user. I have applied your code
and it's something like this:
Either using a guest or root we can only get the permitted tabs of the
guest. Can we have the kimchi/config/ui/tabs.xml changed automatically
according to the logged in user. Role distinguishing can be done in the
back-end and add the right mode to this xml file automatically? Or else
we might need to find other ways to transfer the user roles.
Best regards
Wang Wen
On 7/11/2014 10:16 AM, alinefm(a)linux.vnet.ibm.com wrote:
From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
Kimchi has 2 user roles: "admin" with full control of Kimchi features
and "user" with limited access
To describe how each tab should be displayed for a user, the "mode"
attribute should be added.
The "mode" attribute values are:
- none: do not show the tab;
- admin: full instance access;
- read-only: read-only access;
- byInstance: each resource will have its configuration sent by the
backend;
The user will only be able to manage the guests he/she is assigned for,
because that the guest tab has 'mode' == admin
As a user can edit a guest, he/she may need to know which networks
and storage pools are configured, so set network and storage tab 'mode'
to read-only.
And as user should not perform any operation on host or templates, set
their 'mode' attributes to 'none'.
Signed-off-by: Aline Manera <alinefm(a)linux.vnet.ibm.com>
---
config/ui/tabs.xml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/config/ui/tabs.xml b/config/ui/tabs.xml
index b045521..b8e7bd6 100644
--- a/config/ui/tabs.xml
+++ b/config/ui/tabs.xml
@@ -1,22 +1,22 @@
<?xml version="1.0" encoding="utf-8"?>
<tabs>
- <tab>
+ <tab mode="none">
<title>Host</title>
<path>tabs/host.html</path>
</tab>
- <tab>
+ <tab mode="admin">
<title>Guests</title>
<path>tabs/guests.html</path>
</tab>
- <tab>
+ <tab mode="none">
<title>Templates</title>
<path>tabs/templates.html</path>
</tab>
- <tab>
+ <tab mode="read-only">
<title>Storage</title>
<path>tabs/storage.html</path>
</tab>
- <tab>
+ <tab mode="read-only">
<title>Network</title>
<path>tabs/network.html</path>
</tab>
6:28 a.m.
New subject: [PATCH 2/2] authorization: Add "mode" attribute to describe user view
On 07/11/2014 03:31 AM, Wen Wang wrote:
Thanks Aline, I think there might be some issues by changing the xml
file manually. From the *tabs.xml* we get the mode that a user should
have but it doesn't change when we change user. I have applied your code
and it's something like this:
Either using a guest or root we can only get the permitted tabs of the
guest. Can we have the kimchi/config/ui/tabs.xml changed automatically
according to the logged in user. Role distinguishing can be done in the
back-end and add the right mode to this xml file automatically? Or else
we might need to find other ways to transfer the user roles.
From what we have discussed in "[Kimchi-devel] RFC: Design of
Authorization in Kimchi" I understood the "mode" attribute will only be
used for a "user" role and ignored if the user has a "admin" role as
he/she has full control on kimchi
Example, in JS would have a code like:
if "admin" in roles:
# upload all tabs
elif "user" in roles:
# read mode attribute
But thinking in the future roles we will have we will need to do what
you proposed by changing tabs.xml automatically.
I will send a V2 patch with that
Thanks for the review.
Best regards
Wang Wen
On 7/11/2014 10:16 AM, alinefm(a)linux.vnet.ibm.com wrote:
> From: Aline Manera<alinefm(a)linux.vnet.ibm.com>
>
> Kimchi has 2 user roles: "admin" with full control of Kimchi features
> and "user" with limited access
> To describe how each tab should be displayed for a user, the "mode"
> attribute should be added.
> The "mode" attribute values are:
>
> - none: do not show the tab;
> - admin: full instance access;
> - read-only: read-only access;
> - byInstance: each resource will have its configuration sent by the
> backend;
>
> The user will only be able to manage the guests he/she is assigned for,
> because that the guest tab has 'mode' == admin
> As a user can edit a guest, he/she may need to know which networks
> and storage pools are configured, so set network and storage tab 'mode'
> to read-only.
> And as user should not perform any operation on host or templates, set
> their 'mode' attributes to 'none'.
>
> Signed-off-by: Aline Manera<alinefm(a)linux.vnet.ibm.com>
> ---
> config/ui/tabs.xml | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/config/ui/tabs.xml b/config/ui/tabs.xml
> index b045521..b8e7bd6 100644
> --- a/config/ui/tabs.xml
> +++ b/config/ui/tabs.xml
> @@ -1,22 +1,22 @@
> <?xml version="1.0" encoding="utf-8"?>
> <tabs>
> - <tab>
> + <tab mode="none">
> <title>Host</title>
> <path>tabs/host.html</path>
> </tab>
> - <tab>
> + <tab mode="admin">
> <title>Guests</title>
> <path>tabs/guests.html</path>
> </tab>
> - <tab>
> + <tab mode="none">
> <title>Templates</title>
> <path>tabs/templates.html</path>
> </tab>
> - <tab>
> + <tab mode="read-only">
> <title>Storage</title>
> <path>tabs/storage.html</path>
> </tab>
> - <tab>
> + <tab mode="read-only">
> <title>Network</title>
> <path>tabs/network.html</path>
> </tab>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
12:55 p.m.
New subject: [PATCH 2/2] authorization: Add "mode" attribute to describe user view
On 07/11/2014 08:28 AM, Aline Manera wrote:
On 07/11/2014 03:31 AM, Wen Wang wrote:
> Thanks Aline, I think there might be some issues by changing the xml
> file manually. From the *tabs.xml* we get the mode that a user should
> have but it doesn't change when we change user. I have applied your code
> and it's something like this:
>
>
>
> Either using a guest or root we can only get the permitted tabs of the
> guest. Can we have the kimchi/config/ui/tabs.xml changed automatically
> according to the logged in user. Role distinguishing can be done in the
> back-end and add the right mode to this xml file automatically? Or else
> we might need to find other ways to transfer the user roles.
>
From what we have discussed in "[Kimchi-devel] RFC: Design of
Authorization in Kimchi" I understood the "mode" attribute will only be
used for a "user" role and ignored if the user has a "admin" role as
he/she has full control on kimchi
Example, in JS would have a code like:
if "admin" in roles:
# upload all tabs
elif "user" in roles:
# read mode attribute
But thinking in the future roles we will have we will need to do what
you proposed by changing tabs.xml automatically.
I will send a V2 patch with that
It will not work for us!
Creating the tabs.xml automatically implies in having multiples tabs.xml
file - at least one file per user.
So I suggest turn back to my first proposal and list on xml the "mode"
per "role"
As more roles are added, we just need to update this file to add a new
element *access*
<tab *id=host*>
<*access* role="admin" mode="admin"/>
<*access* role="user" mode="none"/>
<title>Host</title>
<path>tabs/host.html</path>
</tab>
<tab *id=guests*>
<*access* role="admin" mode="admin"/>
<*access* role="user" mode="byinstance"/>
<title>Guests</title>
<path>tabs/guests.html</path>
</tab>
Then we change /login to return the role per tab:
POST /login {username: ..., password: ...}
{ username: ...,
roles: {host: admin, templates: user, ...}
}
So according to roles we can get the mode each tab is configured.
user_access = login.roles
for tab in user_access:
get mode from xml according to tab and role
I will send an RFC patch with that soon.
Hope it solves our issues.
Thanks for the review.
> Best regards
> Wang Wen
>
> On 7/11/2014 10:16 AM, alinefm(a)linux.vnet.ibm.com wrote:
>> From: Aline Manera<alinefm(a)linux.vnet.ibm.com>
>>
>> Kimchi has 2 user roles: "admin" with full control of Kimchi features
>> and "user" with limited access
>> To describe how each tab should be displayed for a user, the "mode"
>> attribute should be added.
>> The "mode" attribute values are:
>>
>> - none: do not show the tab;
>> - admin: full instance access;
>> - read-only: read-only access;
>> - byInstance: each resource will have its configuration sent by the
>> backend;
>>
>> The user will only be able to manage the guests he/she is assigned for,
>> because that the guest tab has 'mode' == admin
>> As a user can edit a guest, he/she may need to know which networks
>> and storage pools are configured, so set network and storage tab 'mode'
>> to read-only.
>> And as user should not perform any operation on host or templates, set
>> their 'mode' attributes to 'none'.
>>
>> Signed-off-by: Aline Manera<alinefm(a)linux.vnet.ibm.com>
>> ---
>> config/ui/tabs.xml | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/config/ui/tabs.xml b/config/ui/tabs.xml
>> index b045521..b8e7bd6 100644
>> --- a/config/ui/tabs.xml
>> +++ b/config/ui/tabs.xml
>> @@ -1,22 +1,22 @@
>> <?xml version="1.0" encoding="utf-8"?>
>> <tabs>
>> - <tab>
>> + <tab mode="none">
>> <title>Host</title>
>> <path>tabs/host.html</path>
>> </tab>
>> - <tab>
>> + <tab mode="admin">
>> <title>Guests</title>
>> <path>tabs/guests.html</path>
>> </tab>
>> - <tab>
>> + <tab mode="none">
>> <title>Templates</title>
>> <path>tabs/templates.html</path>
>> </tab>
>> - <tab>
>> + <tab mode="read-only">
>> <title>Storage</title>
>> <path>tabs/storage.html</path>
>> </tab>
>> - <tab>
>> + <tab mode="read-only">
>> <title>Network</title>
>> <path>tabs/network.html</path>
>> </tab>
>
>
>
> _______________________________________________
> 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
3817
days inactive
3817
days old
7 comments
3 participants
participants (3)
-
Aline Manera -
alinefm＠linux.vnet.ibm.com
-
Wen Wang