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

On 2014年10月14日 21:03, Aline Manera wrote: > > 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. Why do we do for our own (use objstore to store role/group) which LDAP already be able to cover? LDAP is extensible if we have a cluster to maintain, put authorization in configuration totally lose this extensibility, admin need to change configuration hosts one by one, which objstore also does not able to handle this extendibility. I can't say this approach brings us/users any benefit. Also take a look at openstack, why we can't use the method they already verified to be effective?

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