Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Keystone LDAP default structural class for users

Keystone allows one to specify the objectclass that represents users in LDAP, but is hard-coded to add 'person' as a structural class.

#TODO(termie): turn this into a data object and move logic to driver
class UserApi(common_ldap.EnabledEmuMixIn, common_ldap.BaseLdap):
    DEFAULT_OU = 'ou=Users'

This prevents the usage of custom object classes in an LDAP that do not inherit from person. Person brings attribute baggage along with it. Why is the person structural class hard-coded in here? Shouldn't it be either absent or configurable. If the LDAP class is being specified, let that be the object class and stipulate that it must be structural.

Am I missing something? Is there some rationale for this?