[Kimchi-devel] [PATCH 2/3] authorization: Add "access" elements to tabs.xml to describe user view
Aline Manera
alinefm at linux.vnet.ibm.com
Wed Jul 16 15:13:26 UTC 2014
On 07/16/2014 09:53 AM, Aline Manera wrote:
>
>
> On 07/16/2014 04:38 AM, Royce Lv wrote:
>> This role and mode infomation is stored in tabs.xml,
>> If backend is using this information, I guess its difficult to update
>> operations a role can perform.
>
> The content in the xml is static, ie, it will not change.
> It only describe which view a user role (admin or user) will get in
> Kimchi
>
>> If we are using it in frontend,
>> is that mean user can hack .js to change the access mode?
>> I suppose roles and operations mappings need to be restored in backend
>> db to make sure APIs are protected by authorization?
>>
>
> ACK. But I don't think we need to store that info in a db as it is
> static.
>
> I will create a new API /authorization that returns the map presented
> in the xml.
>
> <tab>: {<role>: <mode>}
>
> Example:
>
> GET /authorization
> {
> "guests": {"admin": "admin",
> "user": "byInstance"},
> "templates": {"admin": "admin",
> "user": "byInstance"}
> ...
> }
>
As we discussed today in the scrum meeting, we will keep the
authorization map in the tabs.xml
The frontend can not guarantee authorization, it must be done in
backend, so even if a hacker change the JS to get the admin view, he/she
will not be able to perform any operation (blocked by backend)
The scrum meeting log can be found at
http://kimchi-project.github.io/kimchi/meetings/kimchi.scrum.2014-07-16-13.04.log.html
>> On 2014年07月16日 03:44, alinefm at linux.vnet.ibm.com wrote:
>>> From: Aline Manera <alinefm at 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 to user, an "access"
>>> element was added to tabs.xml indicating which view mode each role has.
>>>
>>> <access role="..." mode="..."/>
>>>
>>> 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 ("access" parameter);
>>>
>>> The user will only be able to manage the guests he/she is assigned for,
>>> because that the guest tab has 'mode' == by-instance.
>>> That way each VM will have a new parameter "access" indicating if user
>>> has
>>> "full" or "read-only" access to this VM.
>>>
>>> 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 at linux.vnet.ibm.com>
>>> ---
>>> config/ui/tabs.xml | 15 +++++++++++++++
>>> plugins/sample/ui/config/tab-ext.xml | 3 +++
>>> 2 files changed, 18 insertions(+)
>>>
>>> diff --git a/config/ui/tabs.xml b/config/ui/tabs.xml
>>> index b045521..f79684c 100644
>>> --- a/config/ui/tabs.xml
>>> +++ b/config/ui/tabs.xml
>>> @@ -1,22 +1,37 @@
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <tabs>
>>> <tab>
>>> + <access role="admin" mode="admin"/>
>>> + <access role="user" mode="none"/>
>>> +
>>> <title>Host</title>
>>> <path>tabs/host.html</path>
>>> </tab>
>>> <tab>
>>> + <access role="admin" mode="admin"/>
>>> + <access role="user" mode="byInstance"/>
>> Maybe more role for guests? Virtualization admin can create/destroy,
>> guest system admin can start and stop, guest user can just login and
>> logout.
>
> For 1.3 only those 2 roles will be added.
> And then we can add more and more according to our needs.
>
>>> +
>>> <title>Guests</title>
>>> <path>tabs/guests.html</path>
>>> </tab>
>>> <tab>
>>> + <access role="admin" mode="admin"/>
>>> + <access role="user" mode="none"/>
>> I suppose also read-only for 'user', because user may want to browser
>> templates available, check details of the template to make decision
>> about which to use.
>
> A user will no be able to create a VM. So why he/she needs to know
> details about a template as the only proposal of templates is creating
> VMs?
>
> Let me explain you the full idea:
> - For now (1.3) we only have 2 roles: admin and user
> - admin role can do everything in kimchi
> - user role only can manage the VMs assigned to him
>
> After getting it done, we idea is add more roles and levels for users.
> Example:
> - user role only can get the console of a VM he/she is assigned for
> - user role only can start/stop/console of VM ...
> and so on
>
> Because that, the mode for a user role in the guests tab is set to
> "byInstance" as each VM must tell what kind of access the user has to it
>
>
>>> +
>>> <title>Templates</title>
>>> <path>tabs/templates.html</path>
>>> </tab>
>>> <tab>
>>> + <access role="admin" mode="admin"/>
>>> + <access role="user" mode="read-only"/>
>>> +
>>> <title>Storage</title>
>>> <path>tabs/storage.html</path>
>>> </tab>
>>> <tab>
>>> + <access role="admin" mode="admin"/>
>>> + <access role="user" mode="read-only"/>
>>> +
>>> <title>Network</title>
>>> <path>tabs/network.html</path>
>>> </tab>
>>> diff --git a/plugins/sample/ui/config/tab-ext.xml
>>> b/plugins/sample/ui/config/tab-ext.xml
>>> index 8e0b3d3..a1fb1c2 100644
>>> --- a/plugins/sample/ui/config/tab-ext.xml
>>> +++ b/plugins/sample/ui/config/tab-ext.xml
>>> @@ -1,6 +1,9 @@
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <tabs-ext>
>>> <tab>
>>> + <access role="admin" mode="admin"/>
>>> + <access role="user" mode="none"/>
>>> +
>>> <title>SampleTab</title>
>>> <path>plugins/sample/tab.html</path>
>>> </tab>
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
More information about the Kimchi-devel
mailing list