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.
> On /etc/kimchi.conf we will have:
> 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
> 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
Authorization as you listed above spread over hosts, making role
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
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.
> 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.
>> 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
> 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
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.