From alinefm at linux.vnet.ibm.com Wed Jul 16 11:13:33 2014 Content-Type: multipart/mixed; boundary="===============6814480477828996079==" MIME-Version: 1.0 From: Aline Manera To: kimchi-devel at ovirt.org Subject: Re: [Kimchi-devel] [PATCH 2/3] authorization: Add "access" elements to tabs.xml to describe user view Date: Wed, 16 Jul 2014 12:13:26 -0300 Message-ID: <53C69696.4060902@linux.vnet.ibm.com> In-Reply-To: 53C675D8.7080907@linux.vnet.ibm.com --===============6814480477828996079== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. > > : {: } > > 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=E5=B9=B407=E6=9C=8816=E6=97=A5 03:44, alinefm(a)linux.vnet.ibm.c= om wrote: >>> From: Aline Manera >>> >>> 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. >>> >>> >>> >>> 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' =3D=3D 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 >>> --- >>> 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 @@ >>> >>> >>> >>> + >>> + >>> + >>> Host >>> tabs/host.html >>> >>> >>> + >>> + >> 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. > >>> + >>> Guests >>> tabs/guests.html >>> >>> >>> + >>> + >> 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 > > >>> + >>> Templates >>> tabs/templates.html >>> >>> >>> + >>> + >>> + >>> Storage >>> tabs/storage.html >>> >>> >>> + >>> + >>> + >>> Network >>> tabs/network.html >>> >>> 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 @@ >>> >>> >>> >>> + >>> + >>> + >>> SampleTab >>> plugins/sample/tab.html >>> >> > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel --===============6814480477828996079==--