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

[Royce Lv]

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 at linux.vnet.ibm.com 
>>> lvroyce at 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 at 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 at 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.
>>>
>>>
>>>
>>>
>>>
>>
>