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

Tue Oct 14 13:03:08 UTC 2014

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.

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