Use two separate domains for them. Make the userids be "uuid at domainid" to be able distinguish one from the other. On 01/27/2014 04:27 PM, Simon Perfer wrote: > I'm looking to create a simple Identity driver that will look at > usernames. A small number of specific users should be authenticated by > looking at a hard-coded password in keystone.conf, while any other > users should fall back to LDAP authentication. > > I based my original driver on what's found here: > > http://waipeng.wordpress.com/2013/09/30/openstack-ldap-authentication/ > > As can be seen in the github code > (https://raw.github.com/waipeng/keystone/8c18917558bebbded0f9c588f08a84b0ea33d9ae/keystone/identity/backends/ldapauth.py), > there's a _check_password() method which is supposedly called at some > point. > > I've based my driver on this ldapauth.py file, and created an Identity > class which subclasses sql.Identity. Here's what I have so far: > > CONF = config.CONF > > LOG = logging.getLogger(__name__) Roles should also be scopeed-able > > > class Identity(sql.Identity): > > def __init__(self): > > super(Identity, self).__init__() > > LOG.debug('My authentication module loaded') > > > def _check_password(self, password, user_ref): > > LOG.debug('Authenticating via my custom hybrid authentication') > > > username = user_ref.get('name') > > LOG.debug('Username = %s' % username) > > > I can see from the syslog output that we never enter the > _check_password() function. > > > Can someone point me in the right direction regarding which function > calls the identity driver? Also, what is the entry function in the > identity drivers? Why wouldn't check_password() be called, as we see > in the github / blog example above? > > THANKS! > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/4a6168f9/attachment.html>