[RFC] LDAP integration in kimchi
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 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. 3. Module for LDAP operation wrapping: A dedicate module to encapsulate LDAP operations, such as bind/unbind, adding, deleting, query groups/roles. 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. 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.
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@linux.vnet.ibm.com lvroyce@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@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.
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@linux.vnet.ibm.com lvroyce@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. 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@br.ibm.com, you change every config in these hosts. 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. 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.
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.
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@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)?
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.
We need to find a good and consistent way to do that independent of the authentication method to make the UI simpler.
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@linux.vnet.ibm.com lvroyce@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@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@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.
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@linux.vnet.ibm.com lvroyce@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@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@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.
on 2014/10/15 11:07, Royce Lv wrote:
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@linux.vnet.ibm.com lvroyce@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@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?
I have some comments for your consideration. Kimchi is a small project targeting for small/testing/development/on-ramp use case, that is to say, Kimchi should be polite and noninvasive to the environment. Kimchi has to prepare itself to co-exist with other tools. OpenStack is a huge project union which dominates the environment. So not everything that OpenStack can do is what Kimchi also can do. Agree? A company may already have an ldap setup in production, for evaluating Kimchi, the admin may neither want to change the ldap configuration nor give write access to Kimchi. Kimchi may only read the ldap to do authentication. For example, suppose you are in a company named BigBlur ;-), and BigBlur has an ldap containing all the staff information. This ldap is under control of a world wide team, and the fields are fixed. Now a guy in Beijing lab wants to use Kimchi to manage 4 hosts, and he wants to use BigBlur ldap to allow only some of his colleagues to use Kimchi. If Kimchi has to store extended information in ldap, just considering how complicated the process is to communicate with the ldap team, he may just give up ldap and use PAM... I agree to Aline's suggestion. Kimchi can use an outside ldap just to authenticate users. Kimchi can use an inside objectstore to store the authorization matrix, and the groups. This gives us the flexibility to use any authorization scheme, for example, though you and me might be peers in BigBlur's ldap, but you can be the admin and I can be the user in Kimchi. This is just like how Jenkins-ci uses ldap. As regard to the multi-host configuration problem, I think now that we already have peer discovering, we may also have configuration synchronization. For example, when a new Kimchi host is up, the user can "import" the authentication matrix from the other Kimchi host.
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@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.
On 10/15/2014 05:19 AM, Zhou Zheng Sheng wrote:
on 2014/10/15 11:07, Royce Lv wrote:
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@linux.vnet.ibm.com lvroyce@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@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? I have some comments for your consideration.
Kimchi is a small project targeting for small/testing/development/on-ramp use case, that is to say, Kimchi should be polite and noninvasive to the environment. Kimchi has to prepare itself to co-exist with other tools. OpenStack is a huge project union which dominates the environment. So not everything that OpenStack can do is what Kimchi also can do. Agree?
A company may already have an ldap setup in production, for evaluating Kimchi, the admin may neither want to change the ldap configuration nor give write access to Kimchi. Kimchi may only read the ldap to do authentication. For example, suppose you are in a company named BigBlur ;-), and BigBlur has an ldap containing all the staff information. This ldap is under control of a world wide team, and the fields are fixed. Now a guy in Beijing lab wants to use Kimchi to manage 4 hosts, and he wants to use BigBlur ldap to allow only some of his colleagues to use Kimchi. If Kimchi has to store extended information in ldap, just considering how complicated the process is to communicate with the ldap team, he may just give up ldap and use PAM...
I agree to Aline's suggestion. Kimchi can use an outside ldap just to authenticate users. Kimchi can use an inside objectstore to store the authorization matrix, and the groups. This gives us the flexibility to use any authorization scheme, for example, though you and me might be peers in BigBlur's ldap, but you can be the admin and I can be the user in Kimchi. This is just like how Jenkins-ci uses ldap.
When we support more user roles, the idea is to have a new tab on Kimchi to handle that configuration. So in that tab, an admin user can set/change user role for LDAP or PAM users.
As regard to the multi-host configuration problem, I think now that we already have peer discovering, we may also have configuration synchronization. For example, when a new Kimchi host is up, the user can "import" the authentication matrix from the other Kimchi host.
Yeap! That is a good idea. I will add it to our backlog.
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@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.
On 2014年10月16日 01:39, Aline Manera wrote:
On 10/15/2014 05:19 AM, Zhou Zheng Sheng wrote:
on 2014/10/15 11:07, Royce Lv wrote:
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@linux.vnet.ibm.com lvroyce@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@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? I have some comments for your consideration.
Kimchi is a small project targeting for small/testing/development/on-ramp use case, that is to say, Kimchi should be polite and noninvasive to the environment. Kimchi has to prepare itself to co-exist with other tools. OpenStack is a huge project union which dominates the environment. So not everything that OpenStack can do is what Kimchi also can do. Agree?
A company may already have an ldap setup in production, for evaluating Kimchi, the admin may neither want to change the ldap configuration nor give write access to Kimchi. Kimchi may only read the ldap to do authentication. For example, suppose you are in a company named BigBlur ;-), and BigBlur has an ldap containing all the staff information. This ldap is under control of a world wide team, and the fields are fixed. Now a guy in Beijing lab wants to use Kimchi to manage 4 hosts, and he wants to use BigBlur ldap to allow only some of his colleagues to use Kimchi. If Kimchi has to store extended information in ldap, just considering how complicated the process is to communicate with the ldap team, he may just give up ldap and use PAM...
I agree to Aline's suggestion. Kimchi can use an outside ldap just to authenticate users. Kimchi can use an inside objectstore to store the authorization matrix, and the groups. This gives us the flexibility to use any authorization scheme, for example, though you and me might be peers in BigBlur's ldap, but you can be the admin and I can be the user in Kimchi. This is just like how Jenkins-ci uses ldap.
When we support more user roles, the idea is to have a new tab on Kimchi to handle that configuration. So in that tab, an admin user can set/change user role for LDAP or PAM users.
As regard to the multi-host configuration problem, I think now that we already have peer discovering, we may also have configuration synchronization. For example, when a new Kimchi host is up, the user can "import" the authentication matrix from the other Kimchi host.
Yeap! That is a good idea. I will add it to our backlog.
> 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@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.
Since we are going to introduce roles/groups, as you suggested, the roles are going to store in objstore, Still LDAP server holds a large number of people while our kimchi is target to small provisioning for small group of people: Init status: 1. Admin in config file is in admin group with all admin role. 2. Alll users without tag are in the group user with all role of users. Assign vm to a group or user: 1. Create a group in objstore Here reason I tend to avoid using filter string is: (1) Query string will be inconstant for different LDAP setup, and may require knowledge of tree structure of LDAP, also filter string can be varied which needs many input from user. (2) We may just want to add small group of people in the LDAP server from same group,e.g.: we would like to add Zhengsheng and I in a group accessing a kimchi testing machine, and exclude all other Chinese members in the same orgnization, this condition cannot be fulfiled by any filter in the LDAP, because LDAP setup is for enterprise information collection,but not dedicate for virtualization use. While group needs to be the resource collection. 2. Add user to this group Aline gave suggestion to query a user's username and add it to the group, I think this is a good idea. Assign role to user 1. Roles: Currently we have user/admin roles for each tab(we can understand it as an array of APIs in controller) These roles will go to objstore as default roles. 2. We can assign user a role in the Authentication tab to determine if it has access of a group of APIs. View of user and following operation result will up to his role.
Since we are going to introduce roles/groups, as you suggested, the roles are going to store in objstore, Still LDAP server holds a large number of people while our kimchi is target to small provisioning for small group of people:
Init status: 1. Admin in config file is in admin group with all admin role. 2. Alll users without tag are in the group user with all role of users.
Assign vm to a group or user:
1. Create a group in objstore
Here reason I tend to avoid using filter string is: (1) Query string will be inconstant for different LDAP setup, and may require knowledge of tree structure of LDAP, also filter string can be varied which needs many input from user.
(2) We may just want to add small group of people in the LDAP server from same group,e.g.: we would like to add Zhengsheng and I in a group accessing a kimchi testing machine, and exclude all other Chinese members in the same orgnization, this condition cannot be fulfiled by any filter in the LDAP, because LDAP setup is for enterprise information collection,but not dedicate for virtualization use. While group needs to be the resource collection.
While using PAM authentication and assigning groups to VM, I don't want to create those groups and only use them. I know it is hard to do on LDAP, so I suggest only support user assignment when using LDAP authentication. For that we will need a different UI when LDAP is being used.
2. Add user to this group Aline gave suggestion to query a user's username and add it to the group, I think this is a good idea.
I think we can query the user's username when assigning an user to a VM but it is not related to any group.
Assign role to user
1. Roles: Currently we have user/admin roles for each tab(we can understand it as an array of APIs in controller) These roles will go to objstore as default roles.
By now, we don't need to store user/roles on objectstore as we just need to know what are the admin IDs
2. We can assign user a role in the Authentication tab to determine if it has access of a group of APIs. View of user and following operation result will up to his role.
Not sure I understood that point.
On 2014年10月22日 01:34, Aline Manera wrote:
Since we are going to introduce roles/groups, as you suggested, the roles are going to store in objstore, Still LDAP server holds a large number of people while our kimchi is target to small provisioning for small group of people:
Init status: 1. Admin in config file is in admin group with all admin role. 2. Alll users without tag are in the group user with all role of users.
Assign vm to a group or user:
1. Create a group in objstore
Here reason I tend to avoid using filter string is: (1) Query string will be inconstant for different LDAP setup, and may require knowledge of tree structure of LDAP, also filter string can be varied which needs many input from user.
(2) We may just want to add small group of people in the LDAP server from same group,e.g.: we would like to add Zhengsheng and I in a group accessing a kimchi testing machine, and exclude all other Chinese members in the same orgnization, this condition cannot be fulfiled by any filter in the LDAP, because LDAP setup is for enterprise information collection,but not dedicate for virtualization use. While group needs to be the resource collection.
While using PAM authentication and assigning groups to VM, I don't want to create those groups and only use them. I know it is hard to do on LDAP, so I suggest only support user assignment when using LDAP authentication. For that we will need a different UI when LDAP is being used.
2. Add user to this group Aline gave suggestion to query a user's username and add it to the group, I think this is a good idea.
I think we can query the user's username when assigning an user to a VM but it is not related to any group.
Assign role to user
1. Roles: Currently we have user/admin roles for each tab(we can understand it as an array of APIs in controller) These roles will go to objstore as default roles.
By now, we don't need to store user/roles on objectstore as we just need to know what are the admin IDs
2. We can assign user a role in the Authentication tab to determine if it has access of a group of APIs. View of user and following operation result will up to his role.
Not sure I understood that point.
I mean permissions whether you can delete or create vm/storage/network
On 10/22/2014 06:52 AM, Royce Lv wrote:
On 2014年10月22日 01:34, Aline Manera wrote:
Since we are going to introduce roles/groups, as you suggested, the roles are going to store in objstore, Still LDAP server holds a large number of people while our kimchi is target to small provisioning for small group of people:
Init status: 1. Admin in config file is in admin group with all admin role. 2. Alll users without tag are in the group user with all role of users.
Assign vm to a group or user:
1. Create a group in objstore
Here reason I tend to avoid using filter string is: (1) Query string will be inconstant for different LDAP setup, and may require knowledge of tree structure of LDAP, also filter string can be varied which needs many input from user.
(2) We may just want to add small group of people in the LDAP server from same group,e.g.: we would like to add Zhengsheng and I in a group accessing a kimchi testing machine, and exclude all other Chinese members in the same orgnization, this condition cannot be fulfiled by any filter in the LDAP, because LDAP setup is for enterprise information collection,but not dedicate for virtualization use. While group needs to be the resource collection.
While using PAM authentication and assigning groups to VM, I don't want to create those groups and only use them. I know it is hard to do on LDAP, so I suggest only support user assignment when using LDAP authentication. For that we will need a different UI when LDAP is being used.
2. Add user to this group Aline gave suggestion to query a user's username and add it to the group, I think this is a good idea.
I think we can query the user's username when assigning an user to a VM but it is not related to any group.
Assign role to user
1. Roles: Currently we have user/admin roles for each tab(we can understand it as an array of APIs in controller) These roles will go to objstore as default roles.
By now, we don't need to store user/roles on objectstore as we just need to know what are the admin IDs
2. We can assign user a role in the Authentication tab to determine if it has access of a group of APIs. View of user and following operation result will up to his role.
Not sure I understood that point.
I mean permissions whether you can delete or create vm/storage/network
Alright. But we will not do it for 1.4. I mean, when we add it we will add it for PAM and LDAP authentication as both will act the same for authorization.
participants (3)
-
Aline Manera -
Royce Lv -
Zhou Zheng Sheng