<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      For both the 'First Step' and 'Next Step', what I see is as below:<br>
      <br>
      1. Bind roles to users<br>
      2. Bind users to resources<br>
      <br>
      do you think we need to bind role to resources?<br>
      <br>
      For examples, there are 10 vms for a user to handle a task, 5 of
      them are shared servers and 5 of them are workstations.<br>
      I would like to give the user quite limited access to the 5 shared
      servers and full control of the 5 workstations.<br>
      <br>
      Since you have not bind role to resources, no matter how fine
      granularity of roles are provided, no way to control.<br>
      <br>
      Security model is strategic, we need to make sure the fundamental
      model is flexible enough for long term needs. <br>
      <br>
      <br>
      On 1/15/2014 3:03 PM, Shu Ming wrote:<br>
    </div>
    <blockquote cite="mid:52D632AF.7000209@linux.vnet.ibm.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <h1>Background</h1>
      <br>
      In Kimchi, now we have a basic authentication model based on PAM.&nbsp;
      In this model, all the authenticated user get all of the
      privileges to access the resources in Kimchi. However, it is too
      simple to cause some security holes and classifying the user with
      different roles is a way to address the holes. Roles with very
      fine grained privileges need huge effort and time, so here we are
      trying to split the effort with several steps.&nbsp; And we will
      discuss the first step of the effort in the below which can be
      achieved in a certain time bound and reserve the forward
      compatibility for future extensions.<br>
      <br>
      <br>
      <h1>First step of the effort</h1>
      <br>
      In this step, the goal is to authorize the user's action on a
      resource by roles. The user action here is applied by the REST API
      exposed by Kimchi.&nbsp; Every action on Kimchi resources should be
      checked based on the user's role.&nbsp; In this step, we will not try
      to have roles in a very fine granularity. Naturally, three
      permanent roles will be created by default, the system
      administrator role, the infrastructure role and the user role.<br>
      <br>
      &nbsp;&nbsp; * The system administrator get the privileges to manage the
      roles for the other users including assigning a role to a user,
      removing the role from a user &amp;etc.&nbsp; A default user "admink"
      will be created by default with a system administrator role
      assigned to it. And the role of the user "admink" can not be
      modified. <br>
      <br>
      &nbsp;&nbsp; * The infrastructure role get the privileges to&nbsp; manage the
      physical resources and virtual resources including network's
      creation and deletion, create or delete storage storage pools or
      storage volumes' creation and deletion, adding a user to the user
      list of storage storage pool &amp;etc. <br>
      <br>
      &nbsp;&nbsp; * The user role get the privileges to apply action on VMs
      including VMs' starting and stopping, viewing the VM console by
      VNC &amp;etc.<br>
      <br>
      &nbsp;&nbsp; * Some of the change can be enhanced on the existing REST API
      like "DELETE /storagepools/poo1/vo1".&nbsp; But we need create new REST
      APIs for actions like adding a role for a user like " PUT
      /users/user1 {role: "user role"}"<br>
      <br>
      &nbsp;&nbsp; * Database is needed to store the user information including
      roles and resource user list<br>
      <br>
      Beside the privileges inherited from the user's role, Kimchi will
      check if a user get the permission to access a resource based on a
      tuple.&nbsp; The tuple is composed from both the privileges of the user
      and the user list of the resource. An example is, if a user try ti
      delete a storage volume from the stroage pool,&nbsp; Kimchi will check
      if it is assigned a infrastructure role and if it is in the user
      list of the storage pool.<br>
      <br>
      <h1>Next step of the effort</h1>
      <br>
      *&nbsp; The roles are defined in a very fine granularity containing the
      privileges precisely matching what the system administrator
      expects.&nbsp; <br>
      <br>
      *&nbsp; Existing roles can by customized by the system administrator
      from a set of previleges.&nbsp;&nbsp; The set of privileges should be
      pre-defined and hierarchy. <br>
      <br>
      * The system administrator can create new roles with customized
      privileges <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>