[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 12:53:44 UTC 2014



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"}
    ...
}

> 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>
>




More information about the Kimchi-devel mailing list