12:15 p.m.
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.
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.
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
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.
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 ?
We need to find a good and consistent way to do that independent of the
authentication method to make the UI simpler.