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

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