Re: [Kimchi-devel] [RFC] LDAP integration in kimchi

On 10/14/2014 03:59 AM, Royce Lv wrote: > On 2014年10月14日 01:15, Aline Manera wrote: >> >> On 10/13/2014 03:43 AM, Royce Lv wrote: >>> LDAP supports connect to it (bind) for authentication, >>> usr/group/role add/delete for authorization. >>> For kimchi-LDAP integration we need to address following issues: >>> >>> 1. LDAP set up scripts for kimchi: >>> We need to add initial users: guest, admin; roles: netadmin, >>> hostadmin, guestadmin in LDAP server. >>> Adding these schema for user maybe a burden, we may supply a script >>> to init LDAP server configuration >>> >> >> We should be able to work with LDAP setup as it is, ie, without >> requiring any special configuration in the LDAP server for it. >> Today we only have 2 types of users: admin (with full access) and >> normal user (with restricted access). >> Later, when we support more type of users who will assign roles to >> users will be the admin users. >> Example: I am a "admin" user and I give you admin privileges to the >> network tab. I hope to have an UI for it. So user can assign roles >> to users in the UI. (But it is for later) >> >> So my suggestion is have a list of admin IDs in the Kimchi >> configuration file when the authentication method is LDAP. >> Example: >> >> On /etc/kimchi.conf we will have: >> >> [authentication] >> method = ldap | pam >> >> For LDAP method we will have addition config parameters: >> >> # For LDAP authentication >> ldap_server = "" >> ldap_search_base = "" >> ldap_search_filter = "mail=%(username)s" >> ldap_admin_users = "alinefm(a)linux.vnet.ibm.com >> lvroyce(a)linux.vnet.ibm.com" >> >> So after the logging we verify the user against the ldap_admin_users >> to know if this specific user has or not admin privileges. >> That way, we can support login using LDAP and also identify what are >> the admin users without special configuration in the LDAP server. > Well, I still think there are some advantages of using dedicate LDAP > for authentication and authorization. > > 1. If this LDAP is not for kimchi role maintainence, it can just > cover authentication not authorization. Yeap. I think that is the point we are diverging. We will use LDAP server *only for authentication*. Authorization will be handle by Kimchi - in a similar way we do for PAM authentication. > Authorization as you listed above spread over hosts, making role > maintenance difficult. > Thinking about a cluster of hosts, if you want add an admin like > alinefm(a)br.ibm.com, you change every config in these hosts. It will be part of the Kimchi configuration. > > 2. Not convenient for role extension > If you want to levels like: virtualzation_admin(can create/destroy > vm), guest_admin(can start/stop vm),guest_user(can use vm) > We need to extend this configuration and this need kimchi upgrade > while keep it in LDAP you just add LDAP schema. > Thinking about PAM authentication: when we support more user roles, the map user/role will be store internally on Kimchi - let's say on objectstore. So we will provide some APIs to an admin user set/change an user role. We can do the same for LDAP authentication. > Also openstack-keystone both have dedicate LDAP to maintain its > users/roles. > http://www.ibm.com/developerworks/cloud/library/cl-ldap-keystone/index.html > > > > I suggest we aggregate authorization and authentication as they do > for extendibility and integrity of functionality. We don't need to integrate both to have functional setup. As I said before, we will handle Kimchi authorization inside Kimchi for PAM or LDAP authentication as it is only related to Kimchi and a LDAP server has more proposal than it.

>> >> >>> >>> 2. Configuration of using LDAP: >>> Configured to use PAM/LDAP, Connecting to a dedicate LDAP server >>> address(As we may use an LDAP to store information of clustered >>> machine, address can be modified). >>> If this LDAP server does not exist, ask user if they want to setup >>> one, and help them with setup scripts. >>> For this release just support one LDAP per host. >>> >> >> No! >> The LDAP must be setup prior to use it as Kimchi authentication method. >> LDAP configuration is a system admin responsibility. > user may not a LDAP professional and schema writing may be error prone. The user can choose between PAM and LDAP. I don't expect to have non-LDAP expert using this type of authentication. >> >>> 3. Module for LDAP operation wrapping: >>> A dedicate module to encapsulate LDAP operations, such as >>> bind/unbind, adding, deleting, query groups/roles. >> >> I will not add/delete user from a LDAP directory. > See above. >> >>> >>> 4. authentication: >>> We need to abstract authenticate class to be compatible with both >>> PAM and LDAP, and call bind/unbind to implement authentication. >>> >>> 5. authorization: >>> Abstract authentication module to distiguish PAM and LDAP, user >>> name still from cherrypy session, when using LDAP, user/role >>> information are all retrieved from LDAP server. >>> >> >> The username will get from the LDAP server but it is not true for >> user role as I explained above. >> >>> 6. user/role maintenance: >>> Manipulate LDAP to add user, delete user, authorize user with a >>> role, add role/delete role, and so on. >>> This part will not be covered in this release. >> >> No! We will not add/delete any information from the LDAP directory. >> We will only use it for query proposals. >> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >> >> Other point that is important is: how set a user/group to a VM? >> On UI, for PAM authentication, we list all users and groups and let >> user selects which he/she wants to user. >> This approach is unfeasible for a LDAP perspective. > If group design for control of a set of vms or resources(views)? To control vms - which users and groups will have access to a specific vm >> >> The users, from a LDAP perspective, will be the user mail, for >> example, so in this case we could only provide the user a filter box >> and list the available matches in the LDAP server. >> >> For groups, the values will come from LDAP search base and filter ? > That is why I want dedicate LDAP for authorization, > groups/roles/users all supplied. > If we just have user, we need to suplement this part in another data > store, I suppose. The authorization will be handle in the same way for PAM or LDAP authentication, ie, store it internally on Kimchi using objectstore or other type of data structure. >> >> We need to find a good and consistent way to do that independent of >> the authentication method to make the UI simpler. >> >> >> >> >> >